On Thu Sep 2, 2021 at 22:21 CET, Andy Balholm wrote: > You don't need a full PostScript interpreter to use a Type 1 font. They > use a very limited subset of PS.
I surmised as much reading through: - https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf (which is my next target as PK support is about to be committed.) > > 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. ha! interesting. I'll try that. thanks all for the input and pointers, -s > > 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. -- 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/CE01WEP11R03.2OTC43OSTPI4L%40clrinfopc42.
