[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inverted (=reflected) N

At 11:17 AM 98/02/07 GMT, Chris Rowley wrote:

>> Well, they are.  Chuck Bigelow made up what he thought are reasonable
>> glyph names when he designed Lucida Sans Unicode.  And he certainly

>In that case, how can two names exist for some glyphs (for type 1 and PS).

For political reasons :-)  Microsoft took the glyph names we used and
replaced them with others in each case where there were two commonly
used names.  This way they can avoid the `invented elsewhere' problem.
I am being somewhat cynical, but its not that far off the truth, I think.
(There is also the fact that they did have their own tradition of naming
which ended up in the WGL4 character set).

>From my perspective, I will use the Adobe glyph names, because the
PS glyphnames in TT fonts are arbitrary and do not have any effect on
whether you can render conveniently with a glyph (in a TT font, glyphs
are numbered sequently and the `encoding' cmap tables referred to  that 
number, not the glyph name.  In a TT font the glyph name is pretty much
only used when producing PS output and are `dummy' variables that
can be changed without changing the printed result).  

In Type 1 fonts, on the other hand,
gly\ph programs are in a dictionary and are referred to only by name. 
So to go from 16-bit character codes to glyph, there must be a match
established between the character code and the glyph name. This is
done via a fixed table of names.

For the basic 228 characters we have already gotten used to using 
Adobe's names just because it makes life simpler (even if some are
misspelled, like guillemot).  
(The Adobe names even appear in LaTeX 2e as \textxyz).
So using the `standard' Adobe names for more glyphs isn't that different.

>> >But I know that you are talking about a world with fixed names (no
>> >synonyms allowed); but there will never be one such fixed list, so why
>> >not prepare for the world of multiple tables or, better, persuade the
>> >"not made here" worlds to support synonyms.

Actually, I allow for synonyms on my end of the business, which is
translating from glyph names to UNICODE numbers.  See attached
for a part of this.  In addition, there is `dotaccent' == `dot' 
 `hacek' == `caron'  `doubleacute' == `hungarumlaut' etc. 
in a  composite charcater name and so on.
So in going from glyph name in an encoding to UNICODE number, this
can easily be done.  The problem is the rasterizer, which one has
no control over (well, you can change the raw binary, as we do with
Microsofts's buggy T1INSTAL.DLL, but that is painful).

>> but there have been several issues that I have tried to budge either
>> Adobe or MS on that was most frustrating and hopeless.  And I always
>> get amused by postings on comp.text.tex that say something like
>> `pressure should be brought to bear on ....'  What pressure?
>> We can't even get them to fix obvious bugs that would be easy to fix.
>> Because they affect a miniscule fringe of their user population.

>Exactly, so unless you want this situation to become worse, so that
>everyone throughout the world wastes their own time and money filling
>the coffers of 2 or 3 US corporations, you should not simply accept
>this but cooperate with other small/medium institutions who are
>working towards a better future and have, I think, had some influence
>on some aspects of the internals of software such as MS-Word (not that
>it is any less buggy, but bugs in basically sane software are somewhat
>easier to diagnose and cope with).  This is a very slow and
>frustrating process, of course.

Not sure I get that.  Naturally we bombard Adobe, Microsoft, Apple,
HP, Micrografx etc. with a constant stream of bug reports.  But most
of this have no effect whatever.  And the reality is that when something
doesn't work we get blamed or called, since the big boys don't provide
useful tech support.  So we have learnt to go with the flow where possible.
It's satisfying to evangalize, but not a way to survive in business.

>> I know: because their design is flawed, we will rather come up with our own
>> flawed design.  We'll end up with something that almost does the right
>> thing.  Not unlike 8r, which could have been LY1 and been much more 
>> useful.  But that would have been using something that was invented
>> elsewhere.

>I see nothing in this terrible conspiracy called "The TeX World" that
>prevents widespread use of the no doubt highly superior LY1.
>What I spend considerable time trying to provide is a system where
>such a change to a superior system will be easy and transparent to users.

Us too.  It's actually pretty simple.  Just download

	http://www.YandY.com/download/ly1-unix.zip :-)

Regards, Berthold.

static const UNICODE_MAP unicodeMapX[] = {
/*	{ "Dmacron",			0x0110 }, */	/* Dcroat */
	{ "Dslash", 			0x0110 },	/* Dcroat */
	{ "Germandbls",			0x00DF },	/* germandbls */
	{ "Nabla",              0x2207 },	/* gradient */
	{ "Ohm",				0x2126 },	/* Omega */
	{ "Pts",				0x20A7 },	/* peseta */
	{ "SS",					0x00DF },	/* germandbls */
	{ "bom",				0xFEFF },	/* byte order mark */
	{ "careof",             0x2105 },	/* afii61248 */
	{ "cwm",				0xFEFF },	/* zero-width no-break space */
	{ "dash",				0x00AD },	/* hyphen */
	{ "dmacron",			0x0111 },	/* dcroat */
/*	{ "dslash" ,			0x0111 }, */	/* dcroat */
	{ "euro",               0x20AC },	/* Euro */
	{ "increment",			0x2206 },	/* Delta */
	{ "kra",                0x0138 },	/* kgreenlandic */
/*	{ "longs",              0x017F }, */	/* slong */
	{ "micro",				0x00B5 },	/* mu */
	{ "middot",		        0x00B7 },	/* periodcentered */
	{ "nabla",              0x2207 },	/* gradient */
	{ "nbspace",			0x00A0 },	/* space */
	{ "numero",             0x2116 },	/* afii61352 */
	{ "ohm",				0x2126 },	/* Omega */
	{ "overscore",			0x00AF },	/* macron */
/*	{ "overscorecomb",		0x0305 }, */	/* ??? */
	{ "perzero",			0x2030 },	/* perthousand */
	{ "pi1",                0x03D6 },	/* Adobe's omega1 ? */
	{ "sfthyphen",			0x00AD },	/* hyphen */
	{ "sigmafinal",         0x03C2 },	/* sigma1 */
	{ "slong",              0x017F },	/* longs */
	{ "visiblespace",		0x0020 },	/* space */
};