← Back to team overview

openerp-chinese-team team mailing list archive

Re: [Merge] lp:~openerp-chinese-team/openobject-server/V6 into lp:openobject-server

 

> My point is: since reportlab's pdfmetrics is a global variable, for the whole 
> life of the python process (= the server), I don't want to replace all the 
> fonts with /one/ Asian font. 

Sorry, are we still talking about the code that I changed. My changes do
not imply replacing all fonts with /one/ Asian font ;) . 

The DejaVu, Liberation, FreeMono in customfonts.py are all Re-registered
every time the rml report is parsed. The performance impair is
definitely there. We were not aware of the obvious lag is luckily due to
the relative smaller size of those fonts(comparing to Asian fonts).

> Imagine a company that needs to ship invoices to China, Russia and some 
> Western countries. There is no single font that would satisfy all of them, 
> sadly :( .
Actually there are a few of them, some even open sourced. For instance,
the Arial Unicode MS (ARIALUNI.TTF) font allows the display of
characters in most languages. This font contains glyphs for all code
points within the Unicode Standard, version 2.1. 

But, as long as style matters, no one will like to use one font for
all. 
I prefer reportlab to provide a font fallback mechanism as most internet
browser do. I consult a guy from reportlab and he told me that it is in
their to-do list of the future development. But God knows when this
feature will be available. I presume from your previous mail that you
are doing the similar. Did I presume wrongly :)

> 
> So, you may have a 'customfonts.py' table localized to your needs, that has 
> been it's original purpose (hence the name "custom.."), 

Yes, that is what I'm doing and that is where I found that my Chinese
font in the table is re-registered in every report processing time and
caused a unacceptable lag. My patch effectively fixed this problem.

> but I cannot still see 
> a global solution that would let OpenERP work out-of-the box for all 
> countries. Our DejaVu, I think, is the best solution so far.
I think the unenviable font fallback mechanism will best suite to our
need. Currently, yes, the font mapping solution is not so bad, as long
as my patch is merged : ) 
 





References