Open tdewolff opened 4 years ago
The https://github.com/llgcode/draw2d project (by @llgcode) seems to share some similarities with this project.
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:
w/ some math oriented fonts there:
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...
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!
@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!
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:
"embed"
)
the end game being to replace all the cgo bits with pure-Go equivalents (and still pass the infamous "trip" TeX test).
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!
star-tex
looks good! When time permits I'll be looking to incorporate your LaTeX libraries intocanvas
, 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. 🙏
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?
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
.
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 :)
@oliverpool it seems that the TIFF export format supports the CCITT group 3 and 4 compression, does that help you?
@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.
Rendering targets:
Implement backend interface:
QPainter
Related projects: