Obtain good quality OTF conversion

[rhaleblian]

Providing it suits, allow me to accumulate some notes here.

Adobe's AFM specification circa 1998: https://adobe-type-tools.github.io/font-tech-notes/pdfs/5004.AFM_Spec.pdf

Support in Perl for inspecting AFM files/bundles:

AFM(3)                User Contributed Perl Documentation               AFM(3)

NAME
       Font::AFM - Interface to Adobe Font Metrics files

SYNOPSIS
        use Font::AFM;
        $h = new Font::AFM "Helvetica";
        $copyright = $h->Notice;
        $w = $h->Wx->{"aring"};
        $w = $h->stringwidth("Gisle", 10);
        $h->dump;  # for debugging

DESCRIPTION
       This module implements the Font::AFM class. Objects of this class are
       initialised from an AFM (Adobe Font Metrics) file and allow you to
       obtain information about the font and the metrics of the various glyphs
       in the font.

       All measurements in AFM files are given in terms of units equal to
       1/1000 of the scale factor of the font being used. To compute actual
       sizes in a document, these amounts should be multiplied by (scale
       factor of font)/1000.

The adobe-type-tools organization makes reference to AFM, if only implicitly: https://github.com/search?q=org%3Aadobe-type-tools+AFM&type=code

Fonts in NEXTSTEP: https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/Concepts/Fonts.htmld/index.html http://www.faqs.org/faqs/fonts-faq/part12/ https://www.math.utah.edu/~beebe/fonts/next.html

[rhaleblian]

Making a survey of what is exposed in NEXTSTEP itself could be fruitful. I run NEXTSTEP and am interested in porting this font to GNUstep.

[rhaleblian]

Added a ptr to doc from NeXT Inc about fonts.

[rhaleblian]

https://gist.github.com/Alhadis/bfde2fa3f848854c2d45 mentions: bepf Adobe Big Endian Prebuilt Format file

Wikipedia notes: The 68000 family stores multi-byte integers in memory in big-endian order.

[rhaleblian]

Oracle, Sun Solaris doc: https://docs.oracle.com/cd/E19620-01/805-3921/font-3/index.html

And, sure enough, SPARC was big-endian: https://blogs.oracle.com/solaris/post/endianness

Maybe some release of Solaris/SunOS (on SPARC, not x86) can chew on this file and not immediately spit it out.

[rhaleblian]

I'll characterize the problem as one of disassembly or decompilation -- you want to extract the source fonts that got built into the BEPF file. Have not seen anything that does this directly; for indirect references to code that might help, GitHub org adobe-type-tools may have legs. And, it may not be possible; transformation might throw something essential away.

Say you changed the problem to one of "screen-scraping". Then, you want to render the whole font set in proper codepoint locations then capture each glyph's image rect into, say, FontForge, and write the modern formats from there. This might work because we're talking about a prescribed set of bitmap strikes and not outline fonts.

Side note: the first part of the above process is really similar to preparing a hardware texture of a font for an old-school game engine.

[rhaleblian]

BTW i agree with the poster that Ohlfs' work on NeXTSTEP is a best-of-class example of the desktop UX paradigm, and good design period. I didn't realize he made the font too until recently! I am sad to hear he passed; his LinkedIn page is still up.

[rhaleblian]

wait. what. is. this? https://github.com/johnsonjh/NeXTDPS/tree/master/fonts-21/bitmapSources/Ohlfs

Being no expert, these still nonetheless really look like bitmap font source. Let's determine what format these are.

Yippee, it looks like BDF. https://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format I think we can do something with this.

[rhaleblian]

FontForge. Sweet.

[rhaleblian]

https://fontforge.org/docs/tutorial/editexample8.html At this juncture, this issue can close and new issues should attack the problem of transforming the given source material to OTF and TTF. A font developer who understands the gap between the Type 1 days and today is best suited to see what must be added.

possible refs: https://sourceforge.net/p/fontforge/mailman/message/2980543/ https://github.com/Tblue/mkttf

[rhaleblian]

Reopened for visibility. follow-on: #2

[rhaleblian]

Close this when #2 can close.

[rhaleblian]

Let #2 represent future work.

[tweedyf]

@rhaleblian I've been able to construct a vectored OTF version of the font using the BDF sources at /johnsonjh/NeXTDPS/ that also includes the bitmap strikes. (Maybe this solves #5.)

The trick was to amend the BDF files to include the following lines, varying with actual pixel size:

PIXEL_SIZE 18
POINT_SIZE 180
RESOLUTION_X 75
RESOLUTION_Y 75

Then FontForge was able to open them correctly. I fed the resulting FontForge bitmap SFD file from the largest available bitmap (18px) through BitsnPicas to generate a vectored version, then went back into FontForge to import the bitmap strikes. A few of the pixel sizes are one point off – not sure why or how to fix:

Attached is the result as well as a zipped folder of the updated BDF files. (I excluded the 24px file, since it seems to just be a 24px bitmap of Courier rather than the Ohlfs font in that size.)

• Ohlfs.otf.zip
• Ohlfs_updated.zip

[The WorldWideWeb rebuild team at CERN also created a vectored version of Ohlfs for use in that project; the font files are here.]

[tweedyf]

Here also is a version of the OTF font based on the 9,10,12,14px bitmaps, which it turns out are substantially different from the larger sizes.

Smaller:

Larger:

• Ohlfs-14.otf.zip

Edit: Modified the font metadata so that the lighter/smaller font registers as the "light" variant of the heavier/larger one: Ohlfs-Light.otf.zip

[rhaleblian]

Very nice. My BDF tweaks were pretty far off.

A few of the pixel sizes are one point off

Same mileage here, I don't get it either.

It is intuitive to me that the smaller strikes would be different; AIUI it's normal to design those carefully to render as well as possible at those pixel dimensions where you are at the legibility limit and rescaling and antialiasing are your enemies.

Seems likely that we should make this product the release here. I'll find some time to kick it around.

[rhaleblian]

Used the OTFs in macOS, nice. The light and medium variants would want to be combined into one file?

@tweedyf do you want to put in a PR to add those BDFs? They can just go into the root dir, and we should add explanation in the README.

[rhaleblian]

A possible lead on the pixel size discrepancy, from CERN's page:

One issue we ran into is that the pixel size on the original NeXT monitors wasn't quite square.

We ran into a few curious anomalies between 1989 hardware and today. When we took a screenshot it rendered the screen as a data file where each pixel is a square. However, when rendered on the NeXT CRT "Megapixel" monitor, the width of each pixel is actually wider than it is longer. A screenshot doesn’t capture this, it is an aspect of the hardware. The font we created is “correct” and if it were viewed on the NeXT machine it work look perfect, but pixels on our modern LCD monitors are square.  This old character set did not include a full Unicode set of characters. Many of the common accented characters were only available in uppercase.

Saying "anomaly" here when discussing CRTs is to me a bit ahistorical; many CRTs were pixel anamorphic. All NTSC monitors are - the TV Dad and Grandma used to watch Love Boat et al. Anyways.