Re: [go-nuts] Re: fonts, bitmap and the (old TeX) PK file format
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
Re: [go-nuts] Re: fonts, bitmap and the (old TeX) PK file format
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.
Re: [go-nuts] Re: fonts, bitmap and the (old TeX) PK file format
Cool. As to the Postscript interpreter, look at https://github.com/llgcode/ps Also, font specific https://github.com/golang/image/blob/master/font/sfnt/postscript.go Not sure how much either helps towards Type 1 support. Even Adobe is end of lifing Type 1 support, though, so it might be worth seeing if you can find a table of maps to help you find the closest OpenType match instead. Best of luck! -- 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/CAPRFAb_s-DFYezn2m-2NDgq93dvQMCejFBRyeBNhXpm%2BQCtPXg%40mail.gmail.com.
Re: [go-nuts] Re: fonts, bitmap and the (old TeX) PK file format
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.
[go-nuts] Re: fonts, bitmap and the (old TeX) PK file format
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. 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. 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? 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. -- 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/72a52d29-756f-4b6c-abce-fcb9c39eed46n%40googlegroups.com.
