You don't need a full PostScript interpreter to use a Type 1 font. They use a very limited subset of PS.

To embed one in a PDF, I don't think you need to parse it at all, if you know the metrics and the encoding already. You can just embed it as a binary blob, if I'm not mistaken.

Andy

On 9/1/21 1:01 PM, 'Sebastien Binet' via golang-nuts wrote:
Howard,

On Wed Sep 1, 2021 at 18:11 CET, Howard C. Shaw III wrote:
You would implement the Face interface to have your fonts available to
Go's
text drawing routines. You can try using basicfont directly, however it
is
fixedwidth only. But just implementing the interface does not seem that
onerous.

Have a look at https://github.com/hajimehoshi/bitmapfont for an example
of
implementing Face for a mostly fixed-size bitmap font (by the author of
the
Ebiten game engine). hajimehoshi's file gives an example of dealing with
a *mostly* fixed width file, where certain characters (i.e. East Asian
glyphs) can be double-width.

Also https://github.com/textmodes/font

Not https://github.com/usedbytes/fonts - this one does not implement the
Face interface.
thanks for these pointers.
I'll have a look.
(funny my 'bitmap' queries on pkg.go.dev didn't turn them out)

However, while that would gain interoperability of your PK fonts with
Go's
text flow engine.... isn't TeX emulation pretty much going to require
you
roll your own text flow engine anyway? I mean, that is kind of the heart
of
TeX, using font metrics to flow text. And so in that case, looking at
https://github.com/usedbytes/fonts, which ignores the Face and golang
Font
and rolls its own text flow for rendering bitmap fonts onto Images might
actually be a useful example.... but only so far, because I believe it
also
assumes a fixed width font.
yes, TeX has its own set of text shaping algorithms.

in view of being able to display LaTeX equations in Gonum plots, I had
first tried to implement the "matheq" subset of LaTeX:

- https://github.com/go-latex/latex

but, in the end, I went with implementing the full kaboodle:

- https://star-tex.org
- https://star-tex.org/x/tex

And no form of fixed width font handling is going to suffice to mimic
TeX;
but again, really, with TeX what you need to be parsing from the .pk
file
is the font metrics, really. TeX never cared about the glyphs. That is
why
TeX's output was a DVI (DeVice Independent) file that had to be combined
with font files to render an actual printable or viewable output. Except
that I don't know that the PK file even has the font metrics - I think
back
then they were in a separate .tfm file?
correct.

This is relevant because one of the important elements that TeX handled
was
the concept that glyphs, properly kerned, can *overlap*. That you cannot
use the width of the glyph to know how far to move forward to draw the
next
one - that was a separate metric. (Not saying it was the first, just
that
it is one of the important features.)

Again, not to take anything away from having success parsing the .pk
file
format - kudos to you. I'm just not sure not only whether it will
actually
be helpful in emulating TeX, but whether it is even needed.
Theoretically,
you should be able to fully emulate TeX in processing a TeX-format file
into a DVI without ever touching any font glyphs at all, just the
metrics.
yes, DVI is the main output of "old" TeX (nowadays, most TeX engines
directly produce PDFs), with only the "boxes" of the glyphs (using the
TFM data.)
it's only when one issues, say, "dvipdf" that the "bounding boxes" of
each glyph is filled with the actual glyph, drawn from PK fonts (in the
very old days), from Type-1 or TTF fonts.

I have the pure-Go TeX engine that produces a .dvi from a .tex file.
now, with either PK or Type-1 fonts, I'd like to implement a "dvipng"
or "dvipdf" command; hence my query about PK fonts.
(probably the PK fonts will only be workable w/ the "dvipng" command)

Implementing support for Type-1 fonts is quite a bigger toll, as this
means implementing a PostScript interpreter.

Eventually, I'd like to implement a Gio-based viewer for DVI files.

Lots of fun ahead :)

Thanks again for the pointers.

-s


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2de7f944-3a8f-2e17-0804-cd9b0406d40c%40gmail.com.

Reply via email to