From: C J Fynn (cfynn@gmx.net)
Date: Tue May 04 2004 - 07:55:10 CDT
"Doug Ewell" <dewell@adelphia.net> wrote:
> C J Fynn <cfynn at gmx dot net> wrote:
> > "Philippe Verdy" <verdy_p@wanadoo.fr> wrote:
> >> Certainly, but what is the distinction between downloading/
> >> distributing a font or downloading/ditributing a XML file containing
> >> the PUA conventions?
> > One file not two - and some assurance that the custom properties
> > haven't been altered since the font and the document that uses it were
> > created.
> I didn't see Philippe's original post, of course, for reasons that many
> list members will remember. But this response from Chris piqued my
> curiosity. So I went digging into my "Deleted Items" folder, found the
> relevant post from Philippe, and guess what? A miracle happened.
> I AGREE WITH PHILIPPE.
> That is, if there is ever to be a mechanism for specifying properties of
> PUA characters at the user level (Mark Davis' expectation
> notwithstanding), I agree that it should live in an external file or
> table or other data structure, not within a font. And XML would be a
> perfectly suitable format for distributing such a property file.
> Not all font formats, not even all "smart" font formats, can contain all
> of the property information for every character the font supports.
> OpenType/Uniscribe was mentioned as an example where the rendering
> engine does work that would be done by the font in other systems. The
> division of labor between font and engine isn't the same across systems.
> And even if you can tell the font about the directionality and
> default-ignorability of your characters, there are still issues like
> line breaking and mirroring (and maybe others, or maybe those are bad
> examples) that have to be handled outside the font anyway.
> Putting all the property information inside the font forces the user to
> use *only that font* for his PUA needs. There might be a choice of
> fonts that support a particular PUA usage (such as for Klingon -- Mark
> Shoulson, is this true?) and it would not make sense to require all of
> these fonts to be updated to include property information (if that is
> even possible). Better to store the property information separately and
> make it work for any old font the user chooses.
> Storing the custom properties in the font doesn't really provide any
> assurance that they haven't been altered.
Phillipe's suggestion is good. I've no real objection to storing the property
information in an external XML file - storing them in a font table was just a
suggestion.
However, even if some of the info has to be handled outside of the font
rendering system you could store any kind of property info in any sfnt format
font (TT, OT. AAT, Graphite) which allows you to add custom tables - so long as
the specification for such a table had was designed to hold all the properties
that might be needed.
I'm not sure whether anyone would want to use non-standard properties for such
PUA text where they didn't have a font that supported the properties for
display.
Given the nature of the PUA, generic property files supposed to work "for any
old font the user chooses" might be problematic. Where a script hasn't been
standardized different developers might wish to use different character
properties.
One of the reasons I suggested putting the properties in the font was that you
would then be fairly certain of having the properties that font was designed to
work with (and avoid the need of having someone maintain something like a
Con-Script character properties registry).
Anything like this should of course be expressly limited to PUA characters.
- Chris
This archive was generated by hypermail 2.1.5 : Fri May 07 2004 - 18:45:25 CDT