Issue 72129 - ttfonts with bad CMAP but good POST tables can be rescued
Summary: ttfonts with bad CMAP but good POST tables can be rescued
Status: CLOSED FIXED
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.1
Hardware: All Unix, all
: P3 Trivial (vote)
Target Milestone: OOo 2.4
Assignee: hdu@apache.org
QA Contact: issues@gsl
URL:
Keywords:
Depends on:
Blocks: 88376
  Show dependency tree
 
Reported: 2006-11-30 11:45 UTC by caolanm
Modified: 2008-08-22 09:10 UTC (History)
2 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
demo patch to implement (1.56 KB, patch)
2006-11-30 11:46 UTC, caolanm
no flags Details | Diff
demo font (74.83 KB, application/octet-stream)
2006-11-30 11:47 UTC, caolanm
no flags Details
slightly reworked patch (3.80 KB, patch)
2007-08-22 11:42 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2006-11-30 11:45:50 UTC
i.e. the attached font lohit hindi contains glyphs for #, $, %, &, *, + /, 0, 1,
2, 3, 4, 5, 6, 7, 8, 9 but if you type this into OOo and select that font to
display them, then you'll either get [] or some other font will be chosen to
fallback to.

The problem is that our test to find the glyph index cannot find the above
glyphs, but fontconfig is able to do this, i.e. the same chars in gedit will
appear in Lohit Hindi. A "demo" patch is attached to fallback to fontconfig's
glyphindex finder which would allow OOo to display the characters. I suspect
that it's the magic code in fontconfig to look up the name of the character in
the postscript table which allows fontconfig to do this.

But as the fontconfig FcFreeTypeCharIndex is apparently compatible with what we
need, would an alternative patch to on UNX (ugly) dlopen fontconfig and give
calling FcFreeTypeCharIndex a go on failure be desirable ?

Feel free to drop patch from this and either
a) send back to me if the dlopen approach would be worthwhile implementing here
b) hold onto it to investigate improving finding the glyph some other way
c) throw out and say "stinky font"
Comment 1 caolanm 2006-11-30 11:46:23 UTC
Created attachment 41011 [details]
demo patch to implement
Comment 2 caolanm 2006-11-30 11:47:13 UTC
Created attachment 41012 [details]
demo font
Comment 3 philipp.lohmann 2006-11-30 12:56:37 UTC
pl->hdu: your turf
Comment 4 hdu@apache.org 2006-12-01 12:33:18 UTC
This is certainly a bad font, since its CMAP tables don't even mention the
problematic characters. The fix in patch is fine as it doesn't impact good fonts.

We'll have to rework the patch though because psprint already dlopens fontconfig
and gets the symbols it needs from there. This would all be easier if psprint
was part of vcl... :-(

Will apply it in CWS vcl70.
Comment 5 hdu@apache.org 2006-12-07 12:59:13 UTC
We cannot link to fontconfig directly. Psprint currently does it dynamically, so
we either have to use psprint's FontCfgWrapper directly or wrap the
FontCfgWrapper again on the salgdi layer. To get all the functionality required
in the future e.g. for issue 54603, issue 46020, etc. we will need almost all of
fontconfig's symbols, so wrapping the wrapper again is not a good idea.

Exporting psprint's wrapper is also not sufficient, since vcl_core (which
contains gcach_ftyp.cxx) doesn't link to it directly, but only via the
vcl_plugin modules. Since this overmodularization is causing real problems that
cannot be resolved easily without
- introducing a new and very strong dependency
- excessive tunneling and rewrapping and hacking
it is probably best to undo the commits to vcl70, so its 2.2 target is not
endangered.
This issue and the related issues above should probably get their own CWS.
Comment 6 philipp.lohmann 2006-12-07 13:27:27 UTC
If you need fontconfig in gcach_ftyp.cxx, then you have done something wrong
anyway, because you will never have fontconfig on Windows. The so called
"overmodularization" is called system abstraction; i think it is not fair
blaming a multiplatform toolkit for being multiplatform.
Comment 7 hdu@apache.org 2006-12-07 15:13:44 UTC
Well, on WIN platforms we link directly with psprint. Only on UNX platforms
psprint is separated via the plugins, even though psprint is required regardless
of which plugin gets used. Ceterum censeo psprint belongs into vcl_core.
Comment 8 philipp.lohmann 2006-12-07 17:23:28 UTC
If you want psprint in vcl, please do that. However saying we link to psprint on
Windows ist greatly exagerated; we link the fontsubset subdirectory only. The
actual printing part of psprint logically belongs to vcl/unx/source/gdi.
Nevertheless even if you move psprint to vcl it would be wrong to move it into
the independent part.
Comment 9 hdu@apache.org 2007-04-24 15:52:01 UTC
I'll have to make psprint's fontconfig wrapper exportable etc., before I can
apply the patch...
Comment 10 caolanm 2007-08-22 11:42:40 UTC
Created attachment 47717 [details]
slightly reworked patch
Comment 11 caolanm 2007-08-22 11:43:39 UTC
how about the above, would that be acceptable ?
Comment 12 hdu@apache.org 2007-08-22 12:32:29 UTC
@CMC: That's much better, thank you! I applied the patch to CWS vcl82.
I also removed the dependencies of this issue to the other fontconfig issues (46020,54603,64508) since 
the older suggestion to wrap psprint's fontconfig wrapper is no longer needed with the new patch.
Comment 13 philipp.lohmann 2007-09-07 15:45:18 UTC
We'll have to clean up the #ifdef UNX at some point. Would have been nice, if
you had done that now.

Verified, with comments
Comment 14 hdu@apache.org 2007-10-04 10:12:51 UTC
The fix got into SRC680_m231 => closing