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/CDYTEJ7VTKIR.032FA61J5YMH%40zoidberg.