Bjorn:
>You find the solution for most of the themes that have been discussed
lately in the Corporate Use Sub area of unicode used by Adobe:
Sub- and superscript variants, dosless-j, mathematical symbols etc.:
http://partners.adobe.com/asn/developer/typeforum/unicodegn.html
http://partners.adobe.com/asn/developer/typeforum/corporateuse.txt
While Adobe may require such PUA allocations in order to handle rendering of
certain characters in their software at the present tiime, in the long run, use
of the character allocations in corporateuse.txt is a bad idea. It implies the
need to allocate character codes for every glyph that is needed for all scripts.
We don't want to do this. If you read Adobe's documents carefully, you'll see
that they themselves intend this as a stopgap measure until better rendering
technology is available to them.
>I am trying to use unicode internally in a system I am working with, and have
found the codes defined in the corporateuse.txt file quite useful, - actually I
have accepted the range as part of the "standard".
They are useful to you because you don't yet have access to the rendering
technology that you need. The answer is not to promote the use of such codes,
but rather to develop the needed rendering technology.
>It is a pity that the standardizers is not interested in listening to people
that try to implement a practical use of Unicode, where for example dotless j is
really needed in rendering text, together with a lot of the characters listed in
for example Adobes list.
They most certainly are, and are working hard to provide specifications for
implementing the standard. Unfortunately, many implementers don't yet understand
all of the issues involved. These things, of course, take time.
If you look on the road map for unicode they have spent a lot of time filling up
for example the Private Use Area with non-exsisting bullshit like Klingon etc.,
instead if making room for characters that is needed to typeset languages that
exist today.
http://www.indigo.ie/egt/standards/csur/conscript-table.html
My understanding is that the best answer you can get is: Suggest it for Plane-1
which may be useful in a couple of years.
Regarding what is in the roadmap, NONE of it is going into the Private Use Area,
and most of it is intended for people that want to work with them today. The
obstacle is not so much development of the standard (I know people still waiting
for New Tai Lue, Lanna, Silheti, additional Ethiopic, and lots of other scripts,
but those are taking time for lack of expert information on those scripts, and
not for lack of will on the part of the standardisers). The obstacle is with
appropriate technologies for rendering, etc. Please don't attack in a direction
that's not warrented.
>My understanding is that the best answer you can get is: Suggest it for Plane-1
which may be useful in a couple of years.
No, the best answer is that, until you've got applications working with
rendering technology in a way that handles j with diacritics as you need, then
use an expert set font with a dotless j, assign a PUA character *for use by
yourself or within your own group of colleagues or organisation* (but NOT by
large common consent as some sort of quasi-standard), do whatever you need to
get by. But please do not occupy the standardisers with unnecessary requests to
add dotless j or other presentation forms to the standard. We don't need them,
and the standardisers won't add them for that reason.
As for your remaining expletive comments, please show the courtesy expected of
all of us on this list.
Peter
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:48 EDT