More frontends/backends

[tdewolff]

Rendering targets:

• OpenVG: GPU-accelerated vector graphics, see https://github.com/ajstarks/openvg and
  https://github.com/JamesDunne/golang-openvg
• NanoVG: https://github.com/memononen/nanovg unmaintained but may provide helpful insight in how to handle OpenGL backend, see https://github.com/memononen/nanovg/blob/master/src/nanovg.c#L1278 for Bezier tesselation

Implement backend interface:

• Gio: see https://gioui.org/ and https://github.com/ajstarks/giocanvas done
• Draw2D: https://github.com/llgcode/draw2d
• gg: https://github.com/fogleman/gg
• Fyne: https://github.com/fyne-io/fyne
• Gi: https://github.com/goki/gi
• Qt: https://github.com/therecipe/qt using QPainter
• Goey: https://bitbucket.org/rj/goey/src/master/
• ui: https://github.com/andlabs/ui
• File formats: postscript, raw RGBA, svgz, BMP, ICO, PCL, PNM, JPEG2000, CCITT

Related projects:

• Cairo
• Skia (Google)
• Azure (Mozilla)
• Blend2D https://blend2d.com/
• Clutter https://developer.gnome.org/clutter/1.26/ClutterPath.html

[oliverpool]

The https://github.com/llgcode/draw2d project (by @llgcode) seems to share some similarities with this project.

[sbinet]

FYI, wrt your far future plan "Generate TeX-like formulas in pure Go, use OpenType math font such as STIX or TeX Gyre", I've started something along these lines, here:

• https://github.com/go-latex/latex
• https://github.com/go-latex/latex/tree/master/mtex

w/ some math oriented fonts there:

• https://github.com/go-fonts/latin-modern
• https://github.com/go-fonts/stix

I've lost a bit of momentum on the math tex renderer font b/c of golang/freetype not being able to injest latin-modern fonts (the ones used by TeX) and golang.org/x/image/font not implementing everything that would be needed on the rastering front...

[tdewolff]

Thanks @sbinet that looks excellent! I'll integrate your work sometime soon and I'll keep you posted. For now I've lost some momentum on this, but there will be time in the future where I can take up some of the ideas, including this one!

[tdewolff]

@sbinet Please check the develop branch for font/sfnt.go (https://pkg.go.dev/github.com/tdewolff/canvas/font#SFNT), this may help you if you need more control over parsing fonts for go-latex. I guess it would be useful to add the https://docs.microsoft.com/en-us/typography/opentype/spec/math table for that!

[sbinet]

thanks.
what's the difference w/ the golang.org/x/image/font/sfnt stuff? (it's just the SFNT tables exported, right?)

I may take a stab at implementing parsing the MATH table.
doesn't seem too complicated (famous last words...)

in other news, I've wrapped a C/C++ TeX engine and provided it as a Go package:

• https://sr.ht/~sbinet/star-tex (needs Go>=1.16 because of "embed")
  

the end game being to replace all the cgo bits with pure-Go equivalents (and still pass the infamous "trip" TeX test).

[tdewolff]

Yes, there is no difference with golang.org/x/image/font/sfnt except that the tables are exported. I've also added subsetting of fonts.

star-tex looks good! When time permits I'll be looking to incorporate your LaTeX libraries into canvas, thanks!

[kpym]

star-tex looks good! When time permits I'll be looking to incorporate your LaTeX libraries into canvas, thanks!

@tdewolff IMO, the things should go on the opposite direction: star-tex to include canvas in a way to be able to produce different outputs (dvi, pdf, svg, png...).

By the way, one more time personal opinion for what this worth, I think that canvas should concentrate on what it is, a canvas. Do it well and leave "pre-print" complex operations to other libraries or modules. It should be a front end of all output formats. To add capabilities like node in tikz or "rich text" should be optional when we use canvas.

My concern is that if you're trying to put a lot of capabilities on canvas, you won't have time to make everything work properly, have good documentation and complete test coverage. And documentation and testing are absolutely necessary for mass adoption of a library.

Personally I'm fan of unix philisophy "do one thing and do it well". Sorry if my opinion is going against your plans.

One more time, thanks for your fantastic work. 🙏

[tdewolff]

Hi Kroum, thanks for the feedback! I think you're absolutely right, canvas should concentrate on being a building block to draw things with rather than adding more and more features. In particular, the documentation and examples are severely lacking.

I can't guarantee working on maturing the library, because some features are just too interesting! Besides documentation and example, what do you reckon are important steps that need to be complete? Are there any lacking features (dvi or OpenGL output?) or things that need to be improved?

[kpym]

I can't guarantee working on maturing the library, because some features are just too interesting!

@tdewolff I can't blame you for preferring to do fun things instead of writing documentation and tests. Oh, how well I understand you 😛. But it will be a pity to lose potential users when you are so close to the goal, IMO.

Besides documentation and example, what do you reckon are important steps that need to be complete? Are there any lacking features (dvi or OpenGL output?) or things that need to be improved?

Not particularly for me. If I find some time, I would like to improve the LaTeX driver (add settings: output tikz or pgf, save raster images in separate files or ignore them...). We can also imagine adding drivers for metapost, PSTricks, Asymptote...

On the low level side of canvas (libraries that it use), I find that in the "go-images world" is missing jpeg2000 and CCITT (for black and white) compressions. But this is out of the scope of canvas, even if it indirectly concerns the pdf and the tiff drivers.

On the high level side of canvas (libraries that use it), having go port of LaTaX as library will be fantastic, but one more time this, IMO, is out of the scope of canvas.

[oliverpool]

On the low level side of canvas (libraries that it use), I find that in the "go-images world" is missing jpeg2000 and CCITT (for black and white) compressions. But this is out of the scope of canvas, even if it indirectly concerns the pdf and the tiff drivers.

The rendering (converting a canvas to something else) is already decoupled from this library (#41 & #44), so you can implement the Renderer interface to export a Canvas to jpeg2000 or CCITT in any other package.

---

I don't know how feasible / easy it would be to also have decoupling regarding the "frontend", but just like the Renderer it probably needs time to know what is really needed (I feel that decoupling of the svg & pdf packages went well, because it had allowed to gather enough experience to get the exports right).

One thing I would enjoy, would be the ability to import a svg image as path. I took a look at it and it seemed way to complex (so I am using a png version of the svg, which is good enough for my usecase :)

[tdewolff]

@oliverpool it seems that the TIFF export format supports the CCITT group 3 and 4 compression, does that help you?

[kpym]

@tdewolff Yes, TIFF support CCITT, but, as far as I know, there in no CCITT encoding library in go. Decoding in go is ok, if I remember well.