Hi, Just committed a patch for CSS' small-caps, http://www.dillo.org/css_compat/tests/font-variant.html I had to use mbrtowc() because for some reason utf8decode() didn't work for me. I tried: diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h> #include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size); @corvid: do you see why? -- Cheers Jorge.-
Jorge wrote:
I had to use mbrtowc() because for some reason utf8decode() didn't work for me.
I tried:
diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h>
#include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size);
@corvid: do you see why?
I think the 'end' is supposed to point to the byte past the end. (If so, that would mean that I have a bug that happens to have no effect where html.cc checks for ideographic chars.)
On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote:
Jorge wrote:
I had to use mbrtowc() because for some reason utf8decode() didn't work for me.
I tried:
diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h>
#include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size);
@corvid: do you see why?
I think the 'end' is supposed to point to the byte past the end. (If so, that would mean that I have a bug that happens to have no effect where html.cc checks for ideographic chars.)
Yes it works with 'end' pointing to 'next' ;) BTW, misc.c also uses the utf8decode(). I hesitate on whether to call utf8{de,en}code() directly from fltkviewbase.cc and fltkplatform.cc, or to add an API to the platform.hh, and implement it in layout.cc as nextGlyph(). The first one looks simpler. Definitely what I like about using utf8{de,en}code() is that there's no need to alter the locale (LC_CTYPE). -- Cheers Jorge.-
Jorge wrote:
On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote:
Jorge wrote:
I had to use mbrtowc() because for some reason utf8decode() didn't work for me.
I tried:
diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h>
#include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size);
@corvid: do you see why?
I think the 'end' is supposed to point to the byte past the end. (If so, that would mean that I have a bug that happens to have no effect where html.cc checks for ideographic chars.)
Yes it works with 'end' pointing to 'next' ;)
BTW, misc.c also uses the utf8decode().
I hesitate on whether to call utf8{de,en}code() directly from fltkviewbase.cc and fltkplatform.cc, or to add an API to the platform.hh, and implement it in layout.cc as nextGlyph(). The first one looks simpler.
Definitely what I like about using utf8{de,en}code() is that there's no need to alter the locale (LC_CTYPE).
If it's only used in fltk*, I think I'd call it directly.
On Fri, Oct 08, 2010 at 01:20:16PM -0400, Jorge Arellano Cid wrote:
On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote:
Jorge wrote:
I had to use mbrtowc() because for some reason utf8decode() didn't work for me.
I tried:
diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h>
#include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size);
@corvid: do you see why?
I think the 'end' is supposed to point to the byte past the end. (If so, that would mean that I have a bug that happens to have no effect where html.cc checks for ideographic chars.)
Yes it works with 'end' pointing to 'next' ;)
BTW, misc.c also uses the utf8decode().
I hesitate on whether to call utf8{de,en}code() directly from fltkviewbase.cc and fltkplatform.cc, or to add an API to the platform.hh, and implement it in layout.cc as nextGlyph(). The first one looks simpler.
It's ok to call it directly. fltkviewbase.cc is fltk-dependent anyway. But we can't call the fltk-based utf8 methods directly from files in dw/ that don't have the fltk prefix. Cheers, Johannes
On Fri, Oct 08, 2010 at 08:45:21PM +0200, Johannes Hofmann wrote:
On Fri, Oct 08, 2010 at 01:20:16PM -0400, Jorge Arellano Cid wrote:
On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote:
Jorge wrote:
I had to use mbrtowc() because for some reason utf8decode() didn't work for me.
I tried:
diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h>
#include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size);
@corvid: do you see why?
I think the 'end' is supposed to point to the byte past the end. (If so, that would mean that I have a bug that happens to have no effect where html.cc checks for ideographic chars.)
Yes it works with 'end' pointing to 'next' ;)
BTW, misc.c also uses the utf8decode().
I hesitate on whether to call utf8{de,en}code() directly from fltkviewbase.cc and fltkplatform.cc, or to add an API to the platform.hh, and implement it in layout.cc as nextGlyph(). The first one looks simpler.
It's ok to call it directly. fltkviewbase.cc is fltk-dependent anyway. But we can't call the fltk-based utf8 methods directly from files in dw/ that don't have the fltk prefix.
Done! -- Cheers Jorge.-
On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote:
Hi,
Just committed a patch for CSS' small-caps, http://www.dillo.org/css_compat/tests/font-variant.html
I don't think the letterSpacing value needs to be scaled down in the small-caps case. corvid, what do you think? Cheers, Johannes
Johannes wrote:
On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote:
Hi,
Just committed a patch for CSS' small-caps, http://www.dillo.org/css_compat/tests/font-variant.html
I don't think the letterSpacing value needs to be scaled down in the small-caps case. corvid, what do you think?
If letter-spacing were originally specified in pixels or centimeters or something, then it definitely wouldn't. If it were given in ems, I'm not sure. *does the usual "let's see what firefox does"* It appears that firefox doesn't modify letter-spacing.
On Fri, Oct 08, 2010 at 12:27:21PM +0000, corvid wrote:
Johannes wrote:
On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote:
Hi,
Just committed a patch for CSS' small-caps, http://www.dillo.org/css_compat/tests/font-variant.html
I don't think the letterSpacing value needs to be scaled down in the small-caps case. corvid, what do you think?
If letter-spacing were originally specified in pixels or centimeters or something, then it definitely wouldn't. If it were given in ems, I'm not sure. *does the usual "let's see what firefox does"* It appears that firefox doesn't modify letter-spacing.
I tried with ems and FF doesn't touch letter-spacing. Committed a patch to mimic this behaviour. -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de