HDTenEightyP/NetNews huggingface dataset:
From: mmwang@adobe.com (Michael Wang)
Subject: Re: font encoding morass
Organization: Adobe Systems Incorporated
Date: Fri, 21 Aug 1992 17:31:43 GMT

In article <1992Aug21.054826.4016@adobe.com> delahunt@adobe.com (Jim DeLaHunt) writes:
>Well, we weren't talking about this kind of document portability before.
>Unicode only pretends to provide portability of *plain text* across 
>platforms.  Think of it as having the advantages and limitations of plain
>ASCII text.  Formatting and ligature substitution systems like Line Layout
>Manager are (as far as I understand) platform-specific, but can support
>multiple encoding schemes. The PostScript language can describe formatted
>documents in *final form* across platforms.

Well, perhaps the intent of Unicode is only to encode plain text, but if
you look through some of the glyphs it does encode, I would argue they
are there for typographical "richness". For example, look at range
U+2100 -> U+214F. These are "letterlike" symbols including some black
letter characters and some script characters. Or look at U+2150 -> U+218F.
These are additional number forms including roman numerals. Then we have
U+2460 -> U+24FF which are the enclosed alphanumerics. And of course in
range U+2700 -> U+27BF we have all of ITC's Zapf Dingbats.


-- 
Michael Wang
mmwang@adobe.com
Newsgroups: comp.fonts
From: ELURONA@YaleVM.YCC.Yale.Edu (R. Elul)
Subject: Shareware programs for Remapping Fonts
Organization: Yale University
Date: Mon, 17 Aug 92 23:09:55 EDT

I am looking for a Freeware/Shareware program which can remap fonts (either
true-type or type1) to create new fonts. Alternatively, is there an easy way
to remap the keyboard or the fonts from within Windows?
From: bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn)
Newsgroups: comp.fonts
Subject: Re: Why Windows 3.1 blocks out some of the upper ASCII codes?
Date: 19 Aug 92 00:42:39 GMT
In-reply-to: desikacharyk@wl.aecl.ca's message of 18 Aug 92 21:52:10 GMT


In article <18AUG92.15521044@wl.aecl.ca> desikacharyk@wl.aecl.ca writes:

	   I have a Font with all the upper ascii slots (codes from 128-255)
   populated. It is a custom designed font that exists in Type 1 and Type 3
   PS Formats and also in the TrueType Format on Mac. It works fine on
   Mac. I can display and print the whole font on Mac. I have used Altsys
   Corporation's Metamorphasis Professional program to convert it into
   IBM PC compatible Type 1 PS and TrueType formats. When I installed
   these fonts under Windows 3.0, I found that I cannot display/print 27 upper 
   ASCII characters. Then I tried them under Windows 3.1. Things are slightly 

	etc etc

Read it and weep:  there is no fixed relationship between character code
number and character.  This is called the encoding vector and the default
encoding vector differs from platform to platform.  On the Mac it is
`standard roman encoding', in MS Windows it is `Windows ANSI', and who knows
what it is on Unix...

It does not make sense to speak of ASCII codes above 127, since the ASCII 
standard is only defined for codes from 32 to 127 (actually 126 to be
pedantic). 

When you say you can't get a character in positions 208, 215, 221, 222, 240,
253, and 254, this is because Windows ANSI has Eth, multiple, Yacute, Thorn,
eth, yacute, and thorn in those positions, and these characters do not occur
in Mac `standard roman encoding'.  You also say, you can't get anything in
code position 194.  This is probably a typo, since Windows ANSI has
Acircumflex there, which exists in the Mac encoding.  Or maybe you don't
have a character in that position:  Acircumflex is in code position 229 on
the Mac.

DON'T think in terms of NUMBERS, but CHARACTERS (character names maybe).
The whole idea of the PostScript font encoding vector is lost on most
people, including software vendors.  Some font generation software for
example has a fixed hard-wired `encoding vector' which totally defeates the
purpose (i.e. NUL stands for 0, DEL for 127 etc).  It just substitutes
(meaningless) names for numbers...

You can force Windows to NOT reencode the font to Windows ANSI, but this
requires a tool for generating a PFM file with appropriate bits set.  Then
it just shows the characters where they occur in the encoding vector in the
font. Similarly, you can set up the FOND resource in a screen font on the
Mac so as to not reencode to Mac `standard encoding'.  But most people don't
have tools to do things like that.

Also, if you plan to use ATM in Windows and you have accented characters you
cannot use this technique, since ATM has hard-wired positions for accents:
0 for caron, 1 for dotlessi, etc.  This does work fine on the Mac.

Maybe it is time for UNICODE so we can avoid this reencoding mess once and
for all.  Just which the UNICODE priests would believe more in ligatures...

Berthold K.P. Horn
Cambridge, Massachusetts, USA
From: ulma@coli.uni-sb.de (Ulrich Mayring)
Newsgroups: comp.fonts
Subject: Re: SWFTE Typecase
Date: 18 Aug 92 22:20:15 GMT
Organization: U of Saarbruecken, Dept. of Computational Linguistics

hardiman@csd4.csd.uwm.edu (Paul V Hardiman) writes:

>Why is this discussion limited to even point sizes?  I once read an
>article in one of the desktop publishing magazines that pointed out
>that much printed material is done in 11 point, which some studies
>revealed is appropriate for most people.  Since then I've done almost
>all my printed material in 11 point, and have found it comfortable.

Same goes for me, I use 11 point on most documents.
Another thing: Someone wrote in an earlier post, that books are not the
same as DTP documents in this context. Why not?


     Ulrich Mayring
     volksdesign.

       - Im liberalen Sinne heiat liberal nicht nur liberal -
Newsgroups: comp.fonts
From: ulma@coli.uni-sb.de (Ulrich Mayring)
Newsgroups: comp.fonts
Subject: Re: PageMaker text needed
Date: 12 Aug 92 18:23:52 GMT
Organization: U of Saarbruecken, Dept. of Computational Linguistics

karplus@cse.ucsc.edu (Kevin Karplus) writes:

>I am looking for a text which teaches the use of PageMaker (without

>Little of the class time is spent on detailed user guidance, and so a
>good tutorial text is essential.

There is an EXCELLENT book, but maybe, maybe it is only available in 

German. It is called "Professionelles Gestalten mit dem PageMaker 4.0"
and is written by Gert Wiescher, who has studied - as far as I know - under
Erich Spiekermann. The publisher is called Systhema. It focuses on 
learning how to use PageMaker AS WELL as on typography and the examples
are beautiful. Also Gert Wiescher's style is very entertaining. It is fun
to read, even if you don't care about the subject.


     Ulrich Mayring
     volksdesign.

       - Also wir waren mit grau eigentlich sehr zufrieden -     
Newsgroups: comp.fonts
From: tsines@magnus.acs.ohio-state.edu (Todd J Sines)
Subject: Re: Star Trek font?
Organization: The Ohio State University
Date: Sat, 22 Aug 1992 16:24:35 GMT

this font is available at both sumex-aim.stanford.edu and also 
yak.css.itd.umich.edu via anonymous FTP

sines
-- 
    respond>>
    **todd sines----email at: tsines@magnus.acs.ohio-state.edu---digitally.**
    **384 E.17th/Columbus, OH 43201 tel614.299.9529---the rest of the world**
From: bobb@agora.rain.com (Bob Beauchemin)
Newsgroups: comp.fonts
Subject: Hungarian Font
Date: 22 Aug 92 21:17:43 GMT
Organization: Open Communications Forum


  A friend of mine asked if I could locate a Hungarian font in either
Adobe, TrueType, IBM bitmap or Metafont format. Or does the standard
extended ASCII encoding provide the extra Hungarian characters? (...what he
actually is looking for is a Hungarian word processor).

  Thanks,

Bob Beauchemin
bobb@agora.rain.com
From: opstad@Apple.COM (David Opstad)
Newsgroups: comp.fonts
Subject: Re: Unicode and ligatures (was Re: font encoding morass)
Date: 19 Aug 92 23:41:42 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <1992Aug19.120450.1@lucy.claremont.edu> dhosek@lucy.claremont.edu writes:
>And what is this magic method? If it involves, say, some system
>call, then you have two problems: First, the system has to be
>Unicode-knowledgable (in short, the majority of in situ operating
>environments can't use it) and the line breaking software has to
>be willing to interface with this system call. In the case of a
>system like TeX (or any of the systems which use TeX's line
>breaking mechanism), this is likely not a viable choice. TeX
>needs to be able to work (internally) with ligatures as physical
>glyphs. Unicode in this case could be workable as an input
>scheme, but not as a useful coding scheme for fonts.
> 
The only knowledge of Unicode the system has to have is how to map Unicodes
to (initial cuts at) glyphs *for that font*. Once that is done, any
further processing occurs independent of character encoding. Concrete
example: QuickDraw GX on the Mac (which I'm working on). Here, a single font
can have many different 'cmap' tables, which map from various character
encodings to glyph indices in that font. All subsequent processing (such as
formation of ligatures, swashes, kerning, decomposition of ligatures, etc.)
happens in this glyph index space, and is therefore independent of *any*
character encoding.

I'm not sure I understand your point about TeX working with ligatures as
physical glyphs. If I pass GX a string "office" I'll get back widths that
are appropriate to the font being rendered with. One font may have "ffi"
ligatures, another only the "fi" ligature, and still a third no ligatures
at all. The measurements returned will be appropriate to the context. Further,
if these ligatures need to be re-broken for linebreaking purposes, data in
the font again can identify what the whitespace threshholds are before
that breakage happens, and can return appropriate widths.

Your point about Unicode being useful as an input scheme is precisely
correct. In the examples I've cited above, the set of Unicodes mapped
by the 'cmap' table may only number a couple of hundred, but the glyph
repertoire in the font may number in the thousands. There doesn't need
to be a one-to-one mapping, since the Unicodes aren't intended to
convey appearance, but just meaning. As I mentioned in my previous link,
appearance is the responsibility of something other than the character
encoding.

Your analogy of Unicode to ASCII is right on the money. I agree that Unicode
is not the answer to questions of appearance (although, as described above,
it can certainly be used as the input to the process of generating an
appearance for a string of text).

Dave Opstad
Line Layout Weenie
From: churchh@ut-emx.uucp (Henry Churchyard)
Newsgroups: comp.fonts
Subject: Re: Hebrew ATM fonts.
Summary: shaloold.zip, cica
Date: 18 Aug 92 22:41:18 GMT
Organization: The University of Texas at Austin, Austin, Texas


  As was alluded to a few messages back, a Hebrew Type 1 font (version
1.1.2 of Shalom Old Style) is available under the fonts subdirectory
of ftp.cica.indiana.edu, in the file SHALOOLD.ZIP.  Note however, that
this font does not use the standard IBM-PC encoding of Hebrew
(characters 128-157), but rather maps the Hebrew characters onto the
range 33-126.  Thus this font is more appropriate for using Hebrew in
English-language applications, rather than for use with Hebrew
applications.  There are various ways to get around this if you are
using a full postscript interpreter (the topic of font reeencoding
comes up periodically in comp.lang.postscript), but I don't know about
Deskview/X.

--
         --Henry Churchyard     churchh@emx.cc.utexas.edu
Xref: sparky comp.fonts:2438 comp.periphs.printers:2438
From: willa@vcd.hp.com (Will Allen)
Newsgroups: comp.fonts,comp.periphs.printers
Subject: Re: Fonts for HP Deskjet
Date: 21 Aug 92 15:35:00 GMT
Organization: HP Vancouver Division
X-Useragent: Nuntius v1.1a5

Fonts for HP Deskjet

Rick:

Have your friend call the HP Customer Support Center at 208/323-2551. 
They should be able
to answer her question.

. . .Will

Will Allen
HP Vancouver Division
willa@vcd.hp.com
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Newsgroups: comp.fonts
Subject: Re: Unicode and ligatures (was Re: font encoding morass)
Date: 23 Aug 92 14:33:38 GMT
Organization: UIUC SCS

In article <1992Aug23.081157.28899@linkoping.trab.se> ath@linkoping.trab.se (Anders Thulin) writes:

>In article <665@manutius.UUCP> nickn@manutius (Nick Nussbaum) writes:
>>
>>The standard is a political compromise between the minimal encoding for
>>linguistic purposes and the practical desire to subsume most computer
>>character sets. Note that the unicode spec already includes zapf dingbats,
>>p.c vector characters and 2 dot leaders. Unfortunately it doesn't include
>>the rest of the common ligatures such as those in the Adobe Expert Set.

>What are people assuming Unicode is trying to achieve?

>I always thought it was for information exchange.

>I seem to remember that the draft said that Unicode didn't try to
>encode glyphs -- although in many cases it ended up doing so for one
>reason or another. But: no glyph encoding. Did the final Unicode
>document alter this in any way?

>The discussion here seems to assume that Unicode should encode the
>glyphs: that is, encode the form of the document, rather than it's
>contents.

>Thus, ligature ffi would be different from f+f+i, ranging 2 different
>from non-ranging 2, handwritten R different from Times Roman R
>different from that quaint R used by that German printer (Rausch?)

>We seem to be getting into some kind of Unicode morass here, trying to
>encode all levels (form & contents) of a document with the same code.

>-- 
>Anders Thulin       ath@linkoping.trab.se 
>Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden


Since it has "Uni" in its name, it seems to be trying to be all things
to all people. I certainly can't be that if it does not include ligatures.
It can't be used for encoding fonts, for instance. This there still is
no generally useful way of encoding fonts, resulting in a terrible kludge.

It has everything **including the kitchen sink** (there is a kitchen sink
in Dingbats, isn't there :-) ) and totally useless to me Chinese
characters ... why not the **important** things like ligatures??

Doug McDonald
From: haccme@milton.u.washington.edu (Thomas Ridgeway)
Newsgroups: comp.fonts
Subject: Re: font encoding morass
Date: 20 Aug 92 05:38:15 GMT
Article-I.D.: u.1992Aug20.053815.27076
Organization: University of Washington, Seattle

In article <71384@apple.Apple.COM> opstad@Apple.COM (David Opstad) writes:
>
>Unicode encodes meaning. Ligatures are inappropriate in this context.
>
  written language encodes meaning; unicode encodes symbols of written
  language.  'e' in Italian does not \it{mean} the same thing as 'e'
  in English, but they will be represented with the same Unicode entity.
  The last thing unicode does is encode meaning.

  On `ligatures' unicode has chosen to draw the line in a particular place;
  some would like the line farther to the right, some to the left, but
  it doesn't have much to do with meaning.  Only those who think (seriously,
  there are people who think this!) Unicode has really accounted for ALL
  languages think that the current inventory of characters is adequate---
  and yes, one man's ligature is another man's character.

[high intensity oxidation off]
Tom
From: opstad@Apple.COM (David Opstad)
Newsgroups: comp.fonts
Subject: Re: font encoding morass
Date: 20 Aug 92 06:00:07 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <1992Aug20.013444.6313@adobe.com> mmwang@adobe.com (Michael Wang) writes:
>In the case of document portability, I don't feel that Unicode and
>ligatures are unrelated issues. On the Macintosh, there may be (will
>be) something in the OS that allows automatic substitution of ligatures
>for letter combinations, but what about other platforms? If I create
>a document with a Mac application that uses the Line Layout manager to
>handle ligature substitution and transfer it to another platform that
>doesn't have QuickDraw GX, I'm not going to get the ligatures.

I guess this is the crux of my argument. Is your intent to preserve the
*appearance* of your text, or simply the *content*? If you're trying
to preserve the precise appearance, then why treat it as text at all? Why
not just transmit a bitmap (or Postscript file or Interpress master or...)
and be done with it? If, on the other hand, your job is to render a
simple stream of text that you're receiving, then the model I propose
works just fine--any system (GX or not) will be able to at least minimally
render a stream of Unicodes. Some will be able to give some typographic
elegance at rendering time, and others won't. Some may have richer fonts, and
others won't. In any event the Unicodes at the base of the process are
as simple as possible: they just encode meaning, not appearance.

Dave Opstad
Line Layout Weenie
From: bultman@dgw.rws.nl (G.W.Bultman)
Newsgroups: comp.fonts
Subject: (none)
Date: 13 Aug 1992 01:27:04 -0500
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

Hi, 

Since I cannot read news, please respond to me directly at 
bultman@dgw.rws.nl

I recently found out that someone posts a complete list of 
Metafont fonts to this newsgroup at regular intervals.

Could someone in this group mail me the latest version?

Thanks, 
gwb.

--

    o                                                                o   
  / | \    Gert Bultman <bultman@dgw.rws.nl>   Koningskade 4       / | \  
 o--o--o   Tidal Waters Division               2596 AA The Hague  o--o--o 
  \ | /    Rijkswaterstaat                     The Netherlands     \ | /  
    o                                                                o    

Newsgroups: comp.fonts
From: dhosek@hmcvax.claremont.edu
Subject: Re: font encoding morass
Organization: Harvey Mudd College
Date: 19 Aug 92 22:52:36 PDT

In article <71384@apple.Apple.COM> opstad@Apple.COM (David Opstad) writes:

>Unicode encodes meaning. Ligatures are inappropriate in this context.

Now the copy I have of Unicode is a draft, so this may have
changed since initial publication, but I have a morass (such a
lovely word) of Arabic ligatures in codes FE80-FEFC. Any argument
that allows for final beh to be included must also allow for a
f-i ligature in Latin alphabet typesetting. 

-dh

(Time to duck and cover, I'd say. But before someone turns on the
ol' flamethrower, it would be best to make sure that the "Basic
Glyphs for Arabic Language" is in the final draft.)
From: dhosek@lucy.claremont.edu
Newsgroups: comp.fonts
Subject: Unicode and ligatures (was Re: font encoding morass)
Date: 19 Aug 92 19:04:50 GMT
Organization: Harvey Mudd College

In article <71384@apple.Apple.COM>, opstad@Apple.COM (David Opstad) writes:
> In article <26760@life.ai.mit.edu> bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn) writes:

>>Finally:  Let's hope that UNICODE with its 16-bit characters will help
>>resolve some of these problems.  Although, UNICODE is dead in the
>>water if it does not provide access to ligatures.  For there can be
>>no fine typesetting without ligatures.
 
> As I've said before, Unicode and ligatures are completely orthogonal issues.
> I have on my machine right now a Unicode font containing almost 1,000 glyphs,
> including scores of ligatures. The ligatures, like the rest of the
> typographic richness of this font, are accessed via a well-defined method
> that has *nothing* to do with the character encoding (i.e. Unicode).

And what is this magic method? If it involves, say, some system
call, then you have two problems: First, the system has to be
Unicode-knowledgable (in short, the majority of in situ operating
environments can't use it) and the line breaking software has to
be willing to interface with this system call. In the case of a
system like TeX (or any of the systems which use TeX's line
breaking mechanism), this is likely not a viable choice. TeX
needs to be able to work (internally) with ligatures as physical
glyphs. Unicode in this case could be workable as an input
scheme, but not as a useful coding scheme for fonts.
 
> Unicode encodes meaning. Ligatures are inappropriate in this context.

> Fonts encode appearance. Ligatures, swashes and everything else are very
> appropriate in this context.

In short then, you are saying that Unicode is not designed for,
and cannot be used for doing font encoding? Not that this is
ojectionable, but it should be made explicit that Unicode is only
a data scheme and not a scheme for fonts (much like, say, ASCII
vs. AdobeStandardEncoding). In which case, Unicode is not the
answer to this problem and is at best a distraction.

-dh

Don Hosek                  
dhosek@ymir.claremont.edu  
Quixote Digital Typography 
714-621-1291
From: slibman@hal.gnu.ai.mit.edu (Sanford Libman)
Newsgroups: comp.fonts
Subject: Re: hebrew-looking roman character font
Keywords: psuedo-hebrew
Date: 15 Aug 92 09:36:54 GMT
Organization: /etc/organization

In article <rabjab.7.0@golem.ucsd.edu> rabjab@golem.ucsd.edu (Jeff Bytof) writes:
>I am looking for a font that gives roman characters a Hebrew style.
>I've seen characters like that used as book titles, but haven't found
>anything in electronic form.  

There's one called Shalom, or Peace (I'm not translating; I've seen the font
with both names).  I don't know where to find it on the net (try cica), and 
you didn't indicate what format you need it in.  It's on the Channel1 BBS in
PC Type 1 format.  Actually, try archie with both names to find it on the
net.  Don't be confused by hits on ShalomOldStyle, ShalomStick, and 
ShalomScript.  Those are real Hebrew fonts.

-Sandy
From: ath@linkoping.trab.se (Anders Thulin)
Newsgroups: comp.fonts
Subject: Re: font encoding morass
Date: 23 Aug 92 08:31:10 GMT
Organization: Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

In article <1992Aug21.173143.25986@adobe.com> mmwang@adobe.com (Michael Wang) writes:
>
>Well, perhaps the intent of Unicode is only to encode plain text, but if
>you look through some of the glyphs it does encode, I would argue they
>are there for typographical "richness".

How would the Unicode committe argue? Does the published standard in
any way indicate how users of the standard should interpret inclusion
of a glyph?

The draft seemed to point away from glyph encoding - more towards
concept encoding: one A-ring for letter <A-ring>, one A-ring for
concept Angstrom, one Z for letter Z, one for concept 'integers', one
letter h, one h for Planck (I think it is), one letter e, one math e,
and so on. Did the final standard change this?

I'd say the typographical rendition of these is totaly irrelevant.  If
one culture prefers to render math e in caps with some little fringe
on top, OK, as long as it expresses the concept 'base of natural
logarithms'. But this is just my interpretation of Unicode ...

>For example, look at range
>U+2100 -> U+214F. These are "letterlike" symbols including some black
>letter characters and some script characters.

Used in math writing for certain concepts, yes. Typographical niceties
are surely irrelevant, except to indicate special use.

>Or look at U+2150 -> U+218F.
>These are additional number forms including roman numerals.

These are odd - can't make them out. (Is that CD glyph still there?
It was in the draft - seemed to me like someone copied it without
thinking.)

>Then we have
>U+2460 -> U+24FF which are the enclosed alphanumerics.

Aren't these inherited from some character code - Japanese? If so,
politics may be more important for inclusion that typography.

 And of course in
>range U+2700 -> U+27BF we have all of ITC's Zapf Dingbats.

These are also odd. It can't be ITC Zapf dingbats that are encoded.
It must be some abstract dingbats - but I doubt that there are any.

Weird.

-- 
Anders Thulin       ath@linkoping.trab.se 
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
From: rabjab@golem.ucsd.edu (Jeff Bytof)
Newsgroups: comp.fonts
Subject: hebrew-looking roman character font
Summary: I need a font for roman characters that has a Hebrew style.
Keywords: psuedo-hebrew
Date: 15 Aug 92 01:28:41 GMT
Organization: sio
NNTP-Posting-Host: lutherlab.ucsd.edu

I am looking for a font that gives roman characters a Hebrew style.
I've seen characters like that used as book titles, but haven't found
anything in electronic form.  
Newsgroups: comp.fonts