Subject: Symbols -- Unicode vs font glyphs (was Re: [PATCH] allow printing via PS generation for gnome port)
From: Paul Rohr (paul@abisource.com)
Date: Mon Feb 19 2001 - 12:33:28 CST
Vlad,
This is an excellent analysis of our current awkwardness w.r.t. representing
symbol and wingding characters. Thanks for writing it up so clearly.
I agree that a more extensive fix for 0.7.13 is unneeded.
However, my sense is that the Right Thing to do over the long run would be
to always store the "correct" Unicode codepoints internally, since that's
how everything else in our file format is encoded. (Among other things,
this would eventually allow us to expand the Symbols dialog to insert any
Unicode character, instead of the limited set of font-specific symbols we
currently support.)
I'd love to hear our iconv and/or RemapGlyph experts comment on how hard
it'd be to tackle the additional code required to remap glyphs back into
font-specific indexes when needed. Is there no way to do so efficiently
enough?
Paul
At 08:39 PM 2/19/01 +0400, Vlad Harchev wrote:
>On Mon, 19 Feb 2001, Dom Lachowicz wrote:
>> Also, I have a question about your other message (re: Symbol fonts &
lists)
>> and your patch to fix it - would it be better to output the unicode gylphs
>> instead of using font indexes? Is this possible? This would allow Symbol
>> fonts to work on GnomePrint, IIRC
>
> That's a whole story, IMO. I will call symbols (characters of symbol and
>dingbats font) as Symbols from here.
>
> The unicode value for common symbols is >0x1000 (JFYI).
> We need to investignate how word and etc store Symbols in the .doc and .rtf
>first. They may store correct unicode value (I don't think so - they
shouldn't
>do this for compatibility reasons) or glyph index (the value < 255). (Dom,
>what you can say?).
>
> Here are operations for which it's necessary to use glyph index of Symbols:
>* inserting characters via "insert character" dialog
>* displaying Symbol to screen (since we don't support unicode on most of our
> platforms).
>* generating PS (we don't emit encoding vectors, so all we can do is to
> emit characters with value equal to glyph index when printing to PS).
>* if Symbols are stored as glyphs in .doc and .rtf (at least if some
> versions of Word use indexes for Symbols), and for compatibility with
> other software that uses glyph indexes for Symbols.
>
> Here are operations for which it's necessary to use correct unicode values
>of Symbols:
>* printing via gnome-print
>* exporting to other formats that use unicode values for Symbols (or if
> unicode values of Symbols is used or would be useful when converting
> to that format - e.g. Latex)
>
> It looks that the operations for which it's necessary to know unicode
values
>are not very frequent and not that necessary (IMO). Currently (after my
>patch applied) AW will (still) store Symbols as indexes of glyphs and all
>operations for which it's necessary to know glyph index will work flawlessly
>(proivided patch is applied). As for operations for which unicode value would
>be necessary (for gnome print and exporting to other formats)- they (still)
>won't work since no code is currently present in AW to support benefits of
>representing Symbols as unicode.
>
> When either of approaches for representation of Symbols is used (storing
>unicode values of Symbols or their indexes internally) information about
other
>representation of Symbols would be nice to have (if we aim to perform both
>sets of operations). Of course that information (for converting between
>representations) better be stored in translation tables - but these tables
>will be fontname-dependant - so it would be better to store such tables in
>external files similar to u2g - and will require additional code to load
them,
>maintain and use etc.
>
> As for gnome print:
> Currently AW's code that prints via gnome-print doesn't support outputting
>characters with unicode values > 255 (since GP accepts only 'char' when
>printing IIRC). So this limitation should be removed first (may be there are
>functions for outputting wide characters to gnome-print?).
>
> So, having considered all alternatives, I propose to leave current
>representation of Symbols at least in 0.7.13 (all the code is already there
>and everything works fine). Moving to other representation would require a
lot
>of additional code, the benefits will be really small (provided translation
>tables between different representaions are involved - i.e. provided that
>both sets of operations that require both types of representation of Symbols
>are have to be implemented).
This archive was generated by hypermail 2b25 : Mon Feb 19 2001 - 12:26:45 CST