Support embedded and external fonts

[wader]

@patrislav1 with this you should be able to do ... | ansisvg -fontfile UbuntuMono.woff2 but maybe you wanted to be able to refer to an external file also? i also noticed inkscape was not happy about it, not sure why yet

[patrislav1]

This works for opening in browsers but, AFAICS, Inkscape does not support embedded fonts at all.

So I think to cover all use cases it would be even better to have two options (embedding & external linking)

[wader]

This works for opening in browsers but, AFAICS, Inkscape does not support embedded fonts at all.

Ok I should probably document that somehow.

So I think to cover all use cases it would be even better to have two options (embedding & external linking)

Should be quite easy add. Hardest is probably to decide on how the arguments should work. Any ideas? curl-ish -fontfile @path to embeds, -fontfile path to reference? or having -fontfile and -fontref etc is clearer?

Hmm get a feeling i should redo the whole argument parsing, why it looks and works the way it does now is mostly because how the standard library flags package works in golang.

[patrislav1]

I like -fontfile and -fontref.

[wader]

Noticed now that this is probably broken, i got fooled by the fallback to monospace.

[wader]

Now it should work better. But i'm not sure if the "copy with control sequences" option in iterm2 that i used is weird or if i'm doing something.

This is how iterm2 renders the copied powerline ansi output:

Same thru go run . -fontfile UbuntuMono.woff2 displayed in chrome:

Same color mismatch hmm. Anyways let me know how it goes!

Also this brach have been rebased on top of master to have the params and color fixes

[patrislav1]

Today I couldn't reproduce the color mismatch, but looked into an alignment issue of the filled background rects. One issue was that they were too big, b/c of the extra stroke around them but that was easy to fix. A much more difficult issue is vertical alignment. Turns out that the powerline symbols stretch over the whole character height, and this is somewhat offset to the ansisvg's model of how the text on screen looks like, as in "if you place text at y=0 it may well stretch into negative y territory"

When experimenting with different values for the offset it also turns out that it can have arbitrary (non-integer) numbers, so to apply it to the SVG template it will be necessary to support float (or at least fixed-point-integer) for coordinates. I'm afraid to fully understand this offset problem I first have to write a PhD about typesetting and reverse engineer how woff2 works internally. :rofl:

[wader]

Today I couldn't reproduce the color mismatch

With the param and colors fixes in master? without the param fix i think it probably was very broken.

but looked into an alignment issue of the filled background rects. One issue was that they were too big, b/c of the extra stroke around them but that was easy to fix.

🥳

A much more difficult issue is vertical alignment. Turns out that the powerline symbols stretch over the whole character height, and this is somewhat offset to the ansisvg's model of how the text on screen looks like, as in "if you place text at y=0 it may well stretch into negative y territory"

Oh hmm yes it's quiet hard to follow how all these things interact. Did you try to tweak and remove these https://github.com/wader/ansisvg/blob/master/svgscreen/template.svg?short_path=dc1f9da#L12-L13 i think they might control some of what your describing, not that i really understand what the different values does.

You mean this difference?

When experimenting with different values for the offset it also turns out that it can have arbitrary (non-integer) numbers, so to apply it to the SVG template it will be necessary to support float (or at least fixed-point-integer) for coordinates. I'm afraid to fully understand this offset problem I first have to write a PhD about typesetting and reverse engineer how woff2 works internally. 🤣

😄 if it would help we can probably support some kind of decimal numbers somehow, maybe also for font size.

[wader]

If i look at the arrow codepoint 0xe0b0 in some font inspector like https://fontdrop.info/ it seem like it should be full-height-ish.

Ah now i think i see what you mean by background rect alignment and negative y territory:

[patrislav1]

You mean this difference?

What you can see there (in both examples, IMHO) is two bugs on top of each other, the stroke bug (solved in the PR) and the vertical alignment bug. The vertical alignment bug is much easier to spot when the stroke bug is fixed. I'll try to look into these baseline attributes you pointed at - would be much easier to fix that way, than to retrieve a magic offset value from the font :exploding_head:

[patrislav1]

Today I couldn't reproduce the color mismatch

With the param and colors fixes in master? without the param fix i think it probably was very broken.

Yep I tested with today’s master branch, seems your latest patches fixed it. 👍

[wader]

Looks ok to merge this btw? Good to not end up with too many parallell branches