HDTenEightyP/NetNews huggingface dataset:
From: cdentan@magnus.acs.ohio-state.edu (Catherine M Dentan)
Subject: Sandia font availability?
Keywords: Sandia, Type 1, Truetype, Mac
Organization: The Ohio State University
Distribution: na
Date: Fri, 14 Aug 1992 17:14:30 GMT

Some years ago I bought some bitmap fonts from Dubl-Click, some of
which were the bitmap versions of presumably then-available 
postscript fonts.  The font of interest here is one called Gotham
in the bitmap form.  Further investigation revealed that the
printer font file was called Sandia.  I have not seen this font
in current catalogs.  Does anyone know who the creator/vendor of
Sandia was/is?  I would like to get the Type 1/Truetype version
if it is available.

Thanks in advance for any information.  Reply here or by e-mail
at your discretion.

Cathy
From: howell@blegga.u.washington.edu (David Howell)
Newsgroups: comp.fonts
Subject: Re: Unicode and ligatures (was Re: font encoding morass)
Date: 20 Aug 92 19:07:53 GMT
Article-I.D.: u.1992Aug20.190753.13664
Organization: University of Washington

Well, unless I've grossly misunderstood the arguments so
far, we have two different ways of encoding a document.

1. Unicode. This would be a systems for language 
   transport, and has no utility for fonts.

2. Encoding each glyph with font file name and char. position.
     Avast  (Swash A, st lig, italic, Adobe Garamond) becomes

	AGaramondAlt-Italic 65   (swash A)
	AGaramond-Italic    118  (ascii v)
	AGaramond-Italic    97   (ascii a)
	AGaramodAlt-Italic  115  (ascii s, st lig) in this font

The same word in Utopia, caps and small caps, becomes

	Utopia-Regular		65 (ascii A)
	UtopiaExp-Regular	118
	UtopiaExp-Regular	97
	UtopiaExp-Regular	115
	UtopiaExp-Regular	116

Of course, often whole pages would go past without a font change,
so a character could inherit its font.

If you receive a font in this format, it would be very
difficult to decompose it back to an editable form. The
editor-tool has to know that AGaramodAlt-Italic  115
is an s and a t (in Unicode, or whatever). 

In a recent work, I had section heads set like my first
example (I've taught my copy of TeX to replace the caps
in my AGaramond-Italic with swash caps if I ask it to), but
in one head, the swash A forced the letters too far apart, so
I used a normal Italic A in that spot. If the editor
assumed "heads are in swash, so I'll decompose them now
and recompose when it's time to print," then I'd have
that Swash A back, and the st and ct ligs might
show up as well.

Clearly a system for dealing with font encoding hasn't
even gleamed on the horizon yet. For every glyph in 
a typeset document, we'll need to know

1. The E-Font name.
2. The position in the E-Font.
3. The Unicode character or characters, if any,
	corresponding to that glyph.

I assume that dingbats aren't in Unicode? :)

An E-Font, for this purpose, is related to the old
definition of a font ("A typeface at a certain size.")
An E-Font would be, for example:
	PS-AdobeFont-1.0: CastellarMT 001.000
as taken from the font file.

We'll still have to ship tables containing #3 above with
each document, since without knowing the Unicodes, there
may not be a way to change the font to one you have, if
needed. These could be reduced in size if we made
some encodings required knowledge. ASCII, certainly
(either A-Za-z0-9, or full), perhaps Adobe Standard,
maybe a few others.

OK, so what do we do now? I'd guess QuickDraw GX
(or whatever it was) isn't going to help one bit,
is it?

Dave Howell
SnarkWorks Typesetting and Book Design
hhowell@blegga.cac.washington.edu
From: koontz@cam.nist.gov (John E. Koontz X5180)
Newsgroups: comp.fonts
Subject: Re: Unicode and ligatures (was Re: font encoding morass)
Date: 21 Aug 92 15:53:36 GMT
Organization: National Institute of Standards and Technology, Gaithersburg, MD

It would be nice to see a discussion of how existing applications of
various sorts and existing fonts (including fonts with the Dingbat
symbol set, as Howell has suggested) might be adapted to work with
UNICODE.

----
John E. Koontz (koontz@bldr.nist.gov)

Disclaimer:  Views and recommendations, express or implied, are my own, and
do not reflect the opinion or policy of my employers.
Newsgroups: comp.fonts
From: kchang@ncsa.uiuc.edu (Kenneth Chang)
Subject: Re: designing my own TRUE
Originator: kchang@troon.ncsa.uiuc.edu
Organization: Nat'l Ctr for Supercomp App (NCSA) @ University of Illinois
Date: Wed, 12 Aug 1992 14:38:31 GMT

In article <1992Aug12.121415.4407@wes.on.ca> tomh@wes.on.ca (Tom Haapanen) writes:
>dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin)  writes:
>> The latest MacWarehouse catalog has Fontographer 3.5 for $265.
>> Fontmonger, as you thought, is strictly a conversion program.  It's $95.

>As has been pointed out before, this is incorrect.  While FontMonger isn't
>as *good* for designing fonts as Fontographer, it does work and let you
>create new characters and even entire new fonts.  

Okay, here's the confusion: the original FontMonger for the Macintosh,
version 1.0, does NOT allow designing of fonts. It's a conversion program,
pure and simple. The Windows version does allow the designing of fonts
and I assume the new Mac version (1.5) does as well.
-- 
  Kenneth Chang           | National Center for Supercomputing Applications
  kchang@ncsa.uiuc.edu    |                 Consulting Office/(217)244-1144
-----------------------------------------------------------------------------
  "Everything's entertainment in America eventually" -- Tracy Ullman
Newsgroups: comp.fonts
From: s0558191@titan.ucc.umass.edu (Chris Belanger)
Subject: Changing Font Names in Windows
Organization: University of Massachusetts, Amherst
Distribution: usa
Date: Tue, 18 Aug 1992 01:15:00 GMT

I have recently begun using CorelDraw 3.0 and would like to change
the odd names it gives to fonts to the more correct names. I tried 
changing the names in the win.ini file but the changes were only used when 
I entered the fonts section of the Control Panel. What do I have to do to
make other programs use the new names. Any help is appreciated. Thanks
Chris Belanger
From: bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn)
Newsgroups: comp.fonts
Subject: Re: Unicode and ligatures (was Re: font encoding morass)
Date: 22 Aug 92 12:48:05 GMT
In-reply-to: nickn@manutius.UUCP's message of 21 Aug 92 16:16:41 GMT


In article <665@manutius.UUCP> nickn@manutius.UUCP (Nick Nussbaum) writes:

	....

   ah.. but the UNICODE revisions will include a large number of arabic
   ligatures. And upon request of the National body it will include a large 
   number of Korean Hangul composite characters. In fact, it seems it will 
   include ligatures from any non-European script. It won't include a large 
   set of European ligatures though. Just some. 

Now that is REALLY logical:  ligatures in some languages ARE characters and 
hence should be in UNICODE, while those in other (fi fl ff ffi ffl) are not.
Seems to me we need a `National Body' to lobby for us to rectify this mistake!

   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. 

It's nice to have characters from Zapf Dingbats in there, but are these 
really more important than ligatures in Western languages?  Yes, I have
heard the phiolosphical and religious arguments about how ligatures are 
not `characters', but... 

   Unfortunately it doesn't include
   the rest of the common ligatures such as those in the Adobe Expert Set.
   Those will undoubtably be added by typographic vendors as private 
   extensions. 

That WON'T do. We cannot have commonly used ligatures with different numeric
codes in different vendor's fonts - that takes us right back to the problems
we have right now with encoding.

   What's sadder is that old style ( ranging ) figures aren't distinguished
   from lining figures that are the standard ascii fare. That means that when
   those are added into the private repetoire they'll miss being recognized by
   various functions that are numerically sensitive. Of course, they've always
   been wedged into font mapping for 8 bit codes, but this an old attempt to
   live with the limits of 8 bit encoding. 





Berthold K.P. Horn
Cambridge, Massachusetts, USA
Newsgroups: comp.fonts
From: oneil@cwis.unomaha.edu (Sharon O'Neil)
Subject: Re: SWFTE Typecase
Organization: University of Nebraska at Omaha
Date: Mon, 17 Aug 1992 00:50:30 GMT

dhosek@hmcvax.claremont.edu writes:

>In article <4811@dove.nist.gov>, gilligan@bldrdoc.gov (Jonathan Gilligan 303-497-3861) writes:
>> In article <oneil.713599413@cwis> oneil@cwis.unomaha.edu (Sharon O'Neil) writes:
>>>For most purposes, one would want to use a 12 point type anyway.  In my
>>>opinion, even 10 is a bit small for most purposes because it is somewhat
>>>difficult to read.
> 
>> But if your principle text is set in 12 point, then super and
>> subscripts will be set at a smaller size (typically 9 pt or so), as
>> will footnotes. Super and subscripts in footnotes will be set at a
>> smaller size (about 6 pt). Since I do a lot of technical typesetting
>> (lots of equations), a document set with 12 pt type for the principal
>> face will contain lots of 9 pt and 6 pt type, so it's necessary to
>> have good-looking type at far smaller sizes than I use for the main
>> text.

First of all, I rarely, if ever, have the need to use superscripts or 
subscripts.  (I generally use the MLA format for writing papers, which
eliminates the need for footnotes.  I cite author and page parenthetically.

>To further muddy the waters, I would claim that other than
>single-column printing on US Letter paper or A4, 12 pt is
>distinctly too large for most text applications.

For most of my purposes, 12 point is just about right.  I almost never
have the need for a font smaller than that.  I have just about perfect
vision and I think that an 8 or 10 point letter looks like you're trying
to cram something on the page.  (For word-processed or desktop published
documents.)

>On the other
>hand, with most of the piece-of-crud editing facilities provided
>by WYSIWYG systems, anything smaller than 12pt is distinctly
>illegible on-screen (gosh, what a surprise, the typography for
>on-screen viewing at 70-100dpi is different than that for
>printing at 300+dpi!) so perhaps that's the driving force. Sigh.
>Anyway, you'll be hard pressed to find many books aimed at adult
>readers typeset entirely in 12pt and larger.

A book is /not/ the same as a word-processed or desktop-published
document.  

Sharon O'Neil
oneil@cwis.unomaha.edu


Newsgroups: comp.fonts
From: mwhanley@rodan.acs.syr.edu (Hanley)
Subject: Converting Mac TrueType to Windows
Organization: Syracuse University, Syracuse, NY
Date: Wed, 19 Aug 92 13:05:42 EDT

	Can someone please give me instructions on how to take a Mac
TrueType font and convert it to Windows.  When you get the Mac
TT font it is pure resource fork and no data fork, which means
the IBM sees a 0k file.  Thanks in advance.

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

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
Newsgroups: comp.fonts
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Subject: Re: Unicode and ligatures (was Re: font encoding morass)
Organization: UIUC SCS
Date: Thu, 20 Aug 1992 00:34:53 GMT

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

>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*.

One big point that needs to be made: there has to be, to avoid painful
bitches on the "support"  lines, a way for every text processing system
to access **every** glyph in **every** font, no matter what the
"philosophy" of mapping is or what kind of character codes are used,
or what kind of fonts are used.

TeX, for instance, most certainly makes this rather easy for plain CM fonts: 
you name the font and give a name to the glyph you want by its numeric 
position in the font. It's trivial. 

Doug McDonald
From: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 
Newsgroups: comp.fonts
Subject: Re: designing my own TRUE
Date: 18 Aug 92 23:42:00 GMT
Distribution: world
Organization: Advanced Computer Concepts BBS, New Rochelle, NY 914-654-1981
Reply-To: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 

TH> .dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin)  writes:
  > .> Fontmonger, as you thought, is strictly a conversion program.  It's $95.

TH> .As has been pointed out before, this is incorrect.  While FontMonger isn't
  > .as *good* for designing fonts as Fontographer, it does work and let you
  > .create new characters and even entire new fonts.  No manual hinting capabi
  > .lity, though (although it does do autohinting).

It's certainly not worth fighting about, but I still wouldn't call
FontMonger a design program.  It does allow editing of glyphs, remapping
them, and conversion between many formats.  It's worth the money, but if
I were designing a font from scratch, FontMonger wouldn't be the tool.

Independent of my feelings, nowhere in the user manual does Ares suggest
that FM be used for font design.  That, I think, indicates whether THEY
think it's a design program.

Yes, it's POSSIBLE to use FontMonger to create a font from scratch.
It's also possible to create a program by doing COPY CON FOO.COM. <~>

        D/


TH> .As far as I can tell, FontMonger has three advantages over Fontographer:
  > .        1. It's cheap.  ~$95 now, and I got mine before the price went up.
  > .        2. It does more format conversions, I think.
  > .        3. It's available for PCs (Windows) NOW, not just Real Soon Now.

TH> .That said, I don't think FontMonger and Fontographer are competing tools.
  > .As I see it, Fontographer is aimed at the professional type designer, whil
  > .FontMonger is for casual users who want to convert some fonts and maybe ad
  > .some characters to existing fonts (or maybe create a custom symbol font).

TH> .Oh, and AllType is for people who want to thoroughly mangle their fonts.

TH> .[ \tom haapanen    "i don't even know what street canada is on" -- al capo
  > .[ tomh@wes.on.ca                   "trust the programmer" -- ansi c standa
  > .[ waterloo engineering software      "to thine own self be true" -- poloni

 * OLX 2.2 * Dick.Zeitlin%acc1bbs@ssr.com
                              
Newsgroups: comp.fonts
From: rreiner@nexus.yorku.ca (Richard Reiner)
Subject: Ghostscript fonts -> TT
Organization: York University
Date: Sat, 22 Aug 1992 21:27:19 GMT

Ghostscript comes with many interesting freely distributable fonts
(including the Postscript 35, the Hershey faces, and some others), in
Adobe Type 1 format.  If someone could translate these to TT for the
benefit of Windows and Mac users, this would be a good thing.

Any volunteers who have the appropriate software?  (Ghostscript and
its fonts can be obtained at many ftp sites.  2.5 is the current
version, and is on prep.ai.mit.edu.)

-- 
Richard Reiner........rreiner@nexus.yorku.ca........416-538-3947

Learning, n.  The kind of ignorance distinguishing the studious.
  -- Ambrose Bierce, _The Devil's Dictionary_.
Newsgroups: comp.fonts
From: mmwang@adobe.com (Michael Wang)
Subject: Re: font encoding morass
Organization: Adobe Systems Incorporated
Date: Thu, 20 Aug 1992 01:34:44 GMT

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).

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.

Or take another example. Let's say I have a font on the Mac that includes
small caps in addition to all the other regular characters. I can use
the Line Layout manager to display the small cap characters, even 
though they are not part of the encoding. Again, if I transfer this 
document to another platform, I'm going to lose my small caps since
what is stored in the document are the encoding values for the l.c.
or u.c. letters that were turned into small cap characters, not the
encoding values for the small cap characters themselves.

Unfortunately, expanding Unicode to include ligatures and small caps
is not going to solve the general problem. What do you do if you have
a font with many alternate character forms? Poetica, for example, has
many different versions of the capital letters (not to mention 58
different ampersands). How do you setup Unicode so that it can uniquely
encode each of these different versions? Do you turn Unicode into a
24-bit encoding where each of the regular 16-bit characters can have
256 variations?


-- 
Michael Wang
mmwang@adobe.com
From: rice@cray.com (Jonathan Rice)
Newsgroups: comp.fonts
Subject: Looking for TrueType key-cap font
Summary: ...as in "press [ESC] to quit"
Keywords: tt
Date: 18 Aug 92 21:08:13 GMT
Distribution: usa
Organization: Cray Research, Inc.


I've found two commercial sources of key-cap fonts: one in a package from
Microsoft (about $65) and one in a package from Key Software (about $30).
Before I spend money on one of those, I wonder if anybody knows of a less
expensive (free?) alternative -- I don't need the other 99 fonts in these
packages, just key-caps.

There's a file on cica and elsewhere, ttkboard.zip, but the fonts it contains
1) are ugly, 2) don't include some common IBM PC keys (e.g. Enter), and 3)
make Ventura Publisher crash with a divide by zero exception.

If I have to buy a box full of dozens of TrueType fonts to get this one, any
particular favorites to recommend?  Thanks in advance for posted or mailed
replies.

P.S. most cloned type faces seem to have "give-away" names -- e.g. if the
name starts with "Gar..." it's a Garamond clone; if it's named after a NY
street, it's a Park Avenue clone.  Is this more or less standard practice?
Just curious.

-- 
Jonathan C. Rice  |   rice@zizania.cray.com  |  ...uunet!cray!rice
From: dick@cs.vu.nl (Dick Grune)
Newsgroups: comp.fonts
Subject: Letter Gothic for HP Deskjet/Laserjet on ftp.cs.vu.nl
Date: 18 Aug 92 11:44:46 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam


For those interested in constant-width fonts for the HP Deskjet/Laserjet,
I have just put the font files for the font "Letter Gothic" in the ftp
directory pub/dick/deskjet+laserjet_fonts on the ftp site ftp.cs.vu.nl.
The file names are ltgothic.1st and ltgothic.arc .

The font is a serious manual touch-up of a ltg18 font that has been on many
ftp sites for ages, but which was to horrible to use. Now it's usable; it'll
never be elegant.

The intro file follows below.
					Dick Grune
					Vrije Universiteit
					de Boelelaan 1081
					1081 HV  Amsterdam
					the Netherlands
					dick@cs.vu.nl
----------------------------------------------------------------
Heinlein has given us a simple one-dimensional yard-stick for civilisation:
	1 / infant_mortality .

================================================================
						Sun Aug 16 17:21:57 GMT 1992

The archive ltgothic.arc contains a Letter Gothic font for the HP Deskjet and
Laserjet.

Letter Gothic is a constant-width (monospace) sans-serif font that is very
readable, though somewhat unelegant.  It has nothing to do with English,
German or Italian Gothic (nor with Batman:-).

Presently only an upright 18 pts 7.7 chars/inch ASCII 95 font is available.

The archive contains three files:

	Name               Length    Date     
	=================  ========  =========
	LTG18RPN.DJP          22546  16 Aug 92		The Deskjet font file
	LTG18RPN.SFP          78789  16 Aug 92		The Laserjet font file
	LTG18RPN.SRC          16957  16 Aug 92		The sources in DJEDIT
	             ====  ========
	     Total      3    118292


Compliments and complaints to:
					Dick Grune
					Vrije Universiteit
					de Boelelaan 1081
					1081 HV  Amsterdam
					dick@cs.vu.nl