[reportlab-users] Font mappings, encodings, Macs - r1.20

Marius Gedminas reportlab-users@reportlab.com
Fri, 28 May 2004 18:01:08 +0300

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 28, 2004 at 01:32:21PM +0100, Andy Robinson wrote:
> We have come to the end of a large and frantic wave of
> projects and have a bit more time next month. We are=20
> hoping to do a release 1.20 in June.  Key topics
> are likely to be
> (b) allow an optional 'autoConvertEncoding' mode so that
> - the canvas has a declared encoding,
> - each font has a declared encoding
> - it converts if needed.
> (b) would be big, The Right Thing, but a great way to break
> existing apps. So, we would make it an optional mode
> for at least one release cycle.  We would initially try
> to make sure utf-8 and latin-1 input always did as expected
> irrespective of whether you are

Wouldn't it be simpler to allow the use of Unicode strings rather than
deal with charset conversions?  With Unicode string objects a number of
risk are eliminated, e.g. you won't accidentally pass in a Latin-1
string in a place that expects UTF-8 or vice versa.  And the change
shouldn't break existing apps as they do not use Unicode.  Also, some
other problems with multibyte encodings (like wrapping a line in the
middle of a UTF-8 character) magically disappear if you start
manipulating Unicode instead.

Are there any advantages in dealing with 8-bit strings over Unicode
strings that I am missing?

Marius Gedminas
Committee, n.:
        A group of men who individually can do nothing but as a group
        decide that nothing can be done.
                -- Fred Allen

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

Version: GnuPG v1.2.4 (GNU/Linux)