Since ReportLab supports them, include it in our list, too.
Also, fix the warning that has been appearing in buildbot, about
"code128.py:257: UnicodeWarning ..."
The issue is that string-capable barcodes will only support ASCII chars,
not Unicode. So, cast to str() and let ReportLab's code be happy.
Code was based on patch by: Omar (Pexego), on 22-06-2010
bzr revid: p_christ@hol.gr-20101219201127-mmrsn206a9vldr43
This affects the "Cursor not closed explicitly..." message.
The message is at a "warning" level, but the frame inspection added
some expensive overhead to each cursor open. So, avoid that unless we
are at debug mode.
Conflicts:
bin/sql_db.py
bzr revid: p_christ@hol.gr-20101203164553-vudqkoqb0hpfsocj
We should maybe find a way to let users use their own fonts. At the moment only the 14 default Adobe fonts
(cfr reportlab.reportbase.pdfmetrics.standardFonts) + the ones from customfonts.py will work...
Also got rid of the mapping for ZapfDingBast, as it is a symbol font that cannot be mapped to a regular one.
bzr revid: odo@openerp.com-20101126183043-mrzipe7mdw1zs6g8
Several Linux distros still ship with a broken reportlab config, which
looks at "c:\winnt\fonts" for fonts!
Since they have not fixed that for months, we have to do their job and
have a custom search path of:
- paths from the config file (ttfonts.search_path key)
- sensible defaults for distros, considering os.name and os.uname
- default reportlab path (opt-out with ttfonts.use_default_path=False)
The result is that we will have more chance of locating TTF fonts and
use them (as now required) in the PDF reports.
bzr revid: p_christ@hol.gr-20101126103459-5wv7crw3i3b56adr
Since 91422704d965268f, specifying a font that is not registered with
pdfmetrics will raise an exception. Now, improve that exception to
help the user understand what has gone wrong.
Note: rather than hiding the fact that some font is missing, the admin
should see this error and try to either fix the report (to use a known
font), or register more fonts with the customfonts.py mechanism.
bzr revid: p_christ@hol.gr-20101123153235-c1yri33ptaydb5eo
That snippet of code practically meant "don't use anything but the
standard fonts (by name) in the report". It obviously wanted to prevent the
rml2pdf engine from crashing at a non-existent font.
Well, if the report specifies a font that cannot be mapped by the system,
it should preferably raise an exception (and ask us to fix the report), not
silently ignore the font.
Case 1: the internationalized reports, where font name is used to select a
Unicode-capable font.
Case 2: l10n_ch, where the OCR-B font had to be used (perhaps legal req.)
bzr revid: p_christ@hol.gr-20101123152002-es404ul29rsohzqd
When strings are 8-bit utf8-encoded, unicode will break with the usual:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xce in position ..
message. ustr() will have better luck in those cases.
Conflicts:
bin/report/render/rml2pdf/utils.py
bzr revid: p_christ@hol.gr-20101123151930-8r9q9gg7r902i2nv
This should log the rendering exceptions for reports. Also fix am error at
custom fonts, suppress a message.
Conflicts:
bin/report/render/rml2pdf/utils.py
bzr revid: p_christ@hol.gr-20101123151110-bckon1ji7hul20mp
exception() cannot be called without a string, yet it is even better to
demote those logs to warnings.
Conflicts:
bin/report/render/rml2pdf/utils.py
bzr revid: p_christ@hol.gr-20101123150903-zgiyob943ivcftkq
P. Christeas