Erik van der Poel wrote on 1999-07-24 16:53 UTC:
> > http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts*
> > [...] The Times Roman font covers also the Adobe Symbol encoding.
>
> Just curious, but which ISO 10646 code points did you choose for the
> Adobe Symbol characters that are not in 10646? For example:
>
> F8FC FC # RIGHT CURLY BRACKET TOP # bracerighttp (CUS)
> F8FD FD # RIGHT CURLY BRACKET MID # bracerightmid (CUS)
> F8FE FE # RIGHT CURLY BRACKET BOTTOM # bracerightbt (CUS)
I did the conversion of the Adobe fonts to ISO 10646-1 based on the
Adobe glyph names found in the fonts (because this catches also
unencoded glyphs that are hidden in many of the X11 BDF files but
unavailable under any ISO 8859-1 code), based on the following Adobe
table, which maps Postscript glyph names to UCS:
http://partners.adobe.com/supportservice/devrelations/typeforum/glyphlist.txt
I dropped all characters from the font which are neither in the above
list nor have already a uniXXXX name. This includes the above bracket
fragment characters, for which there exists no Unicode equivalent.
By the way, the bracket fragments were in Frank da Cruz's terminal
symbol proposal, for which I completely forgot to scan and publish a
number of exhibits that Frank has sent me as a basis for further
discussion. Will be on the web next week. Sorry for the delay.
I could probably put the Adobe Symbol bracket fragments into the private
use section, as suggested by the Adobe mapping tables found on the
Unicode ftp server. However, I do not like these particular characters
anyway. I believe that variable size parentheses, braces and brackets
should really be drawn using graphics primitives (spline and line
terminates areas) from a simple algorithmic description in the style
sheet language. Putting them together from font pieces is highly
non-portable and also does not give you the same quality that an
algorithmic specification could provide. If you really want to have
these bracket parts for MathML, I do urge you to reconsider this entire
approach of relying on the font here. The use of special math building
blocks in TeX was *THE* primary reason of why TeX is hardly ever used
with any other fonts than Knuth's Computer Modern, because all others
lack the bracket parts is exactly the alignment in which TeX requires
them.
If TeX had used graphics primitives to draw variable sized parentheses
and square roots, we could much more easily use any arbitrary commercial
of the shelf font with TeX in mathematical texts. Please do not repeat
the same mistake again and lock the math layout functionality to a
single specific font. Please take the variable shapes from the style
sheet and not from the font!
> I believe Frank wanted to know about legacy fonts so that Mozilla could
> try to support those in case the user has not installed the new 10646
> fonts yet. His question arose from a discussion of MathML support in
> Mozilla.
As I said, the Adobe Symbol font is *very* small and will lead to more
frustration than satisfaction among MathML users. It is so small that it
is not necessarily better than nothing. Potential MathML users are today
TeX users. They will have the expectation that at least all TeX symbols
are available, so a real ISO 10646-1 font is clearly the way to go
here.
> > The X server will be extended by a simple
> > conversion function that can generate on-the-fly legacy encodings such
> > as CP1252, KOI-8, CP1252, JIS X 208, etc. from the ISO 10646-1 encoded
> > source fonts.
>
> I'm pretty sure you are aware of the Han unification issues, but I think
> you would be more successful if you treat CJK with care. I.e. when
> making a JIS X 0208 font available, make sure the glyphs are
> "Japanese-style" and not Chinese.
Oh yes, we have at least one Japanese member in the XFree86 team who is
quite vocal about these issues. :) I have started to use the convention
that ADD_STYLE_NAME is set to "ja" in the XLFD of Japanese UCS fonts,
such that we could indeed restrict the set of fonts that we advertise as
being available under a JIS encoding.
Markus
-- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:50 EDT