openerp-chinese-team team mailing list archive

[xrg <xrg@xxxxxxxxx>]

On Monday 20 December 2010, you wrote:
> Thank you for your prompt reply.
> 
> > But, may I suggest the alternative to just register the font once, (with
> > its unique name), like l10n_ch does, wouldn't that solve the problem,
> > too?
> 
> Sorry, I don't quite understand this. In current code, as long as the tag
> '/docinit/registerFont' in rml and/or SetCustomFonts in customfonts module
> involved, those fonts will be re-registered at every report parsing time,
> and thus impact the report process performance  . My changes is just
> simple to ensure that the registered font won't be re-registered, no
> matter what the font it is.

this "no matter ..." is what keeps me from fully agreeing with you (the other 
points are ok). When some document requests a font, we should make sure that 
font is exactly the one it meant to use. 

In other news, I have been reading the code of reportlab, again, today. I was 
reading the part where TTFonts are used section-by-section and embedded in the 
PDF. I think that is the correct place to "attack" the problem. With some 
hacking, we could one day be able to substitute the missing glyphs from 
*other* fonts that have them (like the Xorg's algorithm of displaying 
characters). 
That is, let the report use DejaVu Sans, for all the glyphs this provides. 
And, for those char pages that have no glyphs in DejaVu, use the glyphs of 
some Asian-capable font. 
I believe that would be the best solution.
-- 
https://code.launchpad.net/~openerp-chinese-team/openobject-server/V6/+merge/44193
Your team Open ERP Chinese is subscribed to branch lp:~openerp-chinese-team/openobject-server/V6.