|Summary:||support for detecting dual-width fonts|
|Product:||fontconfig||Reporter:||Noah Levitt <nlevitt>|
|Component:||library||Assignee:||Noah Levitt <nlevitt>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
|Bug Depends on:||82, 108287|
new patch checks that the advances are roughly 2:1 (within 1%)
this patch is the same as above, except that it checks for approximate equality wherever it makes sense
Description Noah Levitt 2003-09-04 21:25:42 UTC
Fontconfig needs support for detecting dual-width fonts.
Comment 2 Noah Levitt 2003-09-04 21:30:21 UTC
There are some unexpected results with this patch, including the following: Lucida Console Regular: spacing = 90 [advances = 1234, 1235] Nimbus Mono L Bold Oblique: spacing = 90 [advances = 600, 740] Courier 10 Pitch Italic: spacing = 90 [advances = 602, 607] (No wonder lucida console wasn't showing up as monospace!) Can we safely ignore these broken fonts?
Comment 3 Noah Levitt 2003-09-04 22:51:45 UTC
Created attachment 55 [details] [review] new patch checks that the advances are roughly 2:1 (within 1%)
Comment 4 Noah Levitt 2003-09-04 23:08:05 UTC
Created attachment 56 [details] [review] this patch is the same as above, except that it checks for approximate equality wherever it makes sense
Comment 5 Noah Levitt 2003-09-04 23:09:53 UTC
The extra change in that last patch sort of belongs in its own bug, but since it is so intertwined in this patch I just added it here. It lets things like "Lucida Console", with its two different but approximately equal advances, pass for monospace fonts.
Comment 6 Noah Levitt 2003-09-05 08:14:41 UTC
Oops: -#define APPROXIMATELY_EQUAL(x,y) (ABS ((x) - (y)) < MAX (ABS (x), ABS (y)) / 100) +#define APPROXIMATELY_EQUAL(x,y) (ABS ((x) - (y)) <= MAX (ABS (x), ABS (y)) / 100) otherwise APPROXIMATELY_EQUAL (50, 50) is false.
Comment 8 Jungshik Shin 2003-09-05 09:53:52 UTC
In addition to the patch committed on May 12 for bug 82, I think this or similar patch is necessary., . With the patch committed on May 12, CJK dual-width fonts don't have 'spacing=100' (monospace) any more in font-cache file. If it's not 'spacing=100' (monospace), there must be something to indicate 'dual-width-ness' of a font as is done in the patch uploaded here. BTW, 1% does not work for 'infamous' Dynalab Chinese fonts. They have the half width of 500 and the full width of 1024 (or 512 : 1000)  http://bugzilla.gnome.org/show_bug.cgi?id=106624  http://email@example.com/msg01375.html
Comment 9 Noah Levitt 2003-09-05 10:12:37 UTC
Should we ignore dynalab, or change it to 3%?
Comment 10 Jungshik Shin 2003-09-05 23:54:34 UTC
It seems like Chinese(Hong Kong and Taiwan) Linux users use them pretty often so that we have to be generous. Is there any non-dual-width font that might be mistaken if we increase the error margin to 3%?
Comment 11 Noah Levitt 2003-09-06 12:42:42 UTC
You're probably right, chances are slim that there could be a proportional width font that happens to match within 3%. 2003-09-06 Noah Levitt <firstname.lastname@example.org> * doc/fontconfig-devel.sgml: * doc/fontconfig-user.sgml: * fontconfig/fontconfig.h: * src/fcname.c: * src/fcfreetype.c (FcFreeTypeCharSetAndSpacing): Add new spacing value FC_DUAL (dual-width, as some CJK fonts). (bug #111) * src/fcfreetype.c (FcFreeTypeCharSetAndSpacing): When checking for monospace and dual-width fonts, allow roughly a 3% variance in the advances.
Comment 12 Jungshik Shin 2003-09-06 12:52:44 UTC
If we want to be 100% sure, we can add a check for U+4E00 (Chinese character number 1) and U+AC00(the first Korean syllable. some Korean fonts don't have a single Chinese character). The presence of either of them, in addition to the fact that it falls within our allowance (3%), should be a sure sign :-)