Add new SVG-based screencast

[mre]

This is taken from https://github.com/sharkdp/fd, so all credits
go to the original authors.

The demo was a bit dated. We've since added more features and
changed the output. On top of that, the gif was a bit blurry.

The new version is in SVG and the commands can be scripted, so
we can change them with a PR and render them through CI.

[lebensterben]

It seems that the emojis are not aligned well in the screencast. Are you using a monospaced font?

[mre]

It seems that the emojis are not aligned well in the screencast. Are you using a monospaced font?

Yeah that's true; noticed that as well. I do use a monospaced font (Monaco). Strangely enough it is properly aligned when I don't run it through svg-term. I could change the font, but I kinda like the style...

[lebensterben]

So under the hood it uses svg-term with the following default font:

https://github.com/marionebl/svg-term/blob/f761fcac7dc77520cb6d7c8e28618cd266f74538/src/default-theme.ts#L52=

It's possible that some codepoints are not available in Monaco so it uses one of the fallback font which somehow is not true monospaced (yes this is very common). The culprit is very likely to be the bitmapped font, which is by definition not true monospaced.

[polarathene]

This is very cool, I didn't know you could animate SVG like this 😀

On the topic of font/emoji, are you talking about the report lines with the symbols on the left? I haven't gotten around to fixing fonts on my system, where emojis/symbols by default only sometimes render correctly. Is that affecting the render here or do you both see the same?

Something like this project might resolve that by embedding the necessary glyphs.

[mre]

On the topic of font/emoji, are you talking about the report lines with the symbols on the left?

Yes

I haven't gotten around to fixing fonts on my system, where emojis/symbols by default only sometimes render correctly. Is that affecting the render here or do you both see the same?

It works for me locally.

Something like this project might resolve that by embedding the necessary glyphs.

Sounds interesting, I'll have a look.

[lebensterben]

Not really worth time fixing the minor issue of emojis...

[lebensterben]

BTW, if we want consistent style for emojis, a good start is https://gitlab.gnome.org/World/design/icon-library

They are all available in Cantarell font (available in Gnome and Google Fonts but notably not present by default in Ubuntu).

[polarathene]

It works for me locally.

Yes, if you have a font with the correct graphemes/glyphs it should display those. Sometimes depending on the app, fallback font searching logic isn't as extensive that you still get those rectangles, which is what happens for me on Chrome I think.

Firefox maintains it's own browser emoji font and has better fallback logic than Chrome (although that recently changed in latest release I think). I am on an ArchLinux based distro though which I am aware of not having a good font config out of the box for this issue, I resolved it once on another system.

Sounds interesting, I'll have a look.

❤️

---

Not really worth time fixing the minor issue of emojis...

Just requires embedding the font. Or expecting everyone to have no rendering issues on their end.

For my system until I mess with font config, it's a common issue. Even on github if someone uses 👍 but with a skin tone variation it just shows as two vertical rectangles next to each other (similar to the screenshot).

I get a similar issue on Android phone which no longer receives updates for new emoji if someone tries to send those in a message.

[lebensterben]

I'm aware of the proposed fix of embedding the font, but it really doesn't worth it.

We move from .gif to .svg based screencast for its lightweights and embedding a font just defeat this purpose...

[polarathene]

We move from .gif to .svg based screencast for its lightweights and embedding a font just defeat this purpose...

• .gif is 97.3 KiB
• .svg is 114.3 KiB

That would be the opposite of reducing file size?

---

Investigation

• font-family in SVG is set to: Monaco, Consolas, Menlo, 'Bitstream Vera Sans Mono', 'Powerline Symbols', monospace.
• Inspecting with Chrome dev-tools, Noto Sans Mono is the font chosen for fonts failing to render, this would be due to monospace generic fallback I think. While the few that do render are Noto Sans Symbols2.
• Even after installing each of those fonts, while they would be used instead of Noto Sans Mono, they did not have the emoji. This required installing Noto Color Emoji font or another that actually has those glyphs.
• Using this python script example to find fonts and this repo for the python-fontconfig package dependency, the only result listed for these was NotoColorEmoji.ttf:

Font glyphs for Summary output:

Additional context for viewers like me where the glyph may not render:

• 📝 (Memo (U+1F4DD) => Summary)
• 🔍 (Magnifying Glass (U+1F50D) => Total)
• ✅ (Checkmark (U+2705) => Successful)
• ⏳ (Hourglass (U+23F3) => Timeouts)
• 🔀 (Shuffle Tracks (U+1F500) => Redirects)
• 👻 (Ghost (U+1F47B) => Excluded)
• ❓ (Red Question Mark (U+2753) => Unknown)
• 🚫 (Prohibited (U+1F6AB) => Errors)

There was one other font listed on the system which supports the emoji assigned to "Total", "Redirects", and "Unknown". That font was NotoSansSymbols2-Regular.ttf. Those ones were from earlier unicode blocks for symbols/pictographs before all the emoji code-points arrived.

---

Subsetting a font to extract only the symbols/emoji needed for an embed

I downloaded the new monochrome emoji font by Google and extracted NotoEmoji-Regular.ttf (to /tmp/font-subset) for creating subsetted font of only those glyphs:

$ docker run --rm -it -v "/tmp/font-subset:/app" talentplatforms/glyphhanger --whitelist="📝🔍✅⏳🔀👻❓🚫" --subset="/app/NotoEmoji-Regular.ttf"

U+23F3,U+2705,U+2753,U+1F47B,U+1F4DD,U+1F500,U+1F50D,U+1F6AB
Subsetting /app/NotoEmoji-Regular.ttf to NotoEmoji-Regular-subset.ttf (was 848.25 KB, now 4.27 KB)
Subsetting /app/NotoEmoji-Regular.ttf to NotoEmoji-Regular-subset.zopfli.woff (was 848.25 KB, now 3.36 KB)
Subsetting /app/NotoEmoji-Regular.ttf to NotoEmoji-Regular-subset.woff2 (was 848.25 KB, now 2.76 KB)

The font does not compress further as woff is already an optimal compressed format. 2.76 KB is a small amount of added weight for consistent rendering. It increases a little bit more with base64 encoding for embedding into the SVG, but still less than 4KB (including the supporting CSS style).

You can get the base64 encoded version with required CSS from this online tool, or just reference that for the CSS and generate base64 in the CLI (using -w 0 to avoid newline based linewrapping on the output):

$ base64 -w 0 /tmp/font-subset/NotoEmoji-Regular-subset.woff2

d09GMgABAAAAAAsMAA8AAAAAESQAAAqzAAEAgwAAAAAAAAAAAAAAAAAAAAAAAAAAHCAGYD9TVEFUHACBRBEICpgolFMBNgIkAxYLFAAEIAWDFgcgFyQYFBs4DqOifnFSMJK/SMg2S3DvmUTRWxZzRsAlhV/3CElmD2ib94QBiKgoKVbiFHVWIGISUto4BbMGK2OJW6vLKsJYZCrodNweIR2o2i7EfwPmTVhNAwSi+9/vV30XfZh11RJIjdBI8+R87jCIaRP1RqkQkolG08TulrJpQ+rrSrYbSysQ641leOXbu3UUQAAAB0xgAZKUnCEFC8AAAIyAszQG54nMBSwANhi7GABhhRdAm0CNsiVYY1EIGkFhBk4oaG+HOflCIR/i3b6OmFcPEwpIRL4pXQZBioQCZ7AEZCKLnGgyOB5RbWXlzQiIGBDREOIeR2kmRAITDltgIBAtpuooALevXlgvyfA1sRL3iP3/+3fBVEoEwuoJoJJXfREQcCoWAWXsJfEAaEC+jUsAwDDdxx4BsIB8hwQAM0dW2COAOSA/thJMzgEZgU+WIWaLoxoBNwz7CKZKAEfUBGRhDZgiaAaTTCKltdKcSb50BtsV50Bg2VmyHGhMW48gKhFjknB4BzKdjLG1JZPxAbSRyTSEsCPyhtHI6TaZTAq9XnpoGxgwyEp1RmPkhiXIw8MNj/F5qpAieLDI/ZBeL9cZjUYEk8mEj8FgAHq9vrZrSOFsHER354AM9P0wBuWIaeioZL/U1TCAmia1t3g4/djqnnL9tClcpetst8OE33AozIubbu64nQhGnJe8x+au4Op6QCtYbhhn6j2/uygFfOulhA7TU/w953pFPaLzdc1DUNl0Gt2TJ4PyTdf0OPPSe+1NQ89K5LFhAHBYGxhka2rtvuvGWGsKW3IE5zVq2ta7YX0bRCmhVE9I7+ujzGCDAd/rfJzbmNQmq6XbJGk6SDGoiEGjz3/UL91wwMt0xc34XI3behSf7TTDwOPHef1IS5UeKRRx8+6uuYe0r8SxW3qtUd7/6kB1x4jTnWNF8aS9WUeIwRCTM24cSorWasZhFWZanYkfqmQ1IuDoQ6joamgEkxd7n16dN44pDNbpL6nkCsNO4sUwrcb2qwWy+I7n9HXxS1WZAzgVuiNgOlwsIcJ/w/lfpNHdQKDkLV3LEPcsImfLSjYepcRsylCu01bhlyvzdPYleZJda/JLhsG+S5W6Gz3XPaB/XqJEvuO5gcjdLU7vWYcz8or83A0ERlVmec9yIUXClx9PQzdSkgsOtRmN8nkjCp7UU7rdIDMYeIq+PgdhkPRCXiKHuzu9kixQoNiKIE/pOP2lOs5ZfGQyA/D3NabfMAZwX4uZ15s/jOEK42guB0O+pkwNuq0gLSIba3o6pEAEvo5Jv/+k2NO43R3ZeCZVVCzkm1Mk+daeymf3gk0+UdVtOjZaRvUgwli7Rq6QaXRZ6jtHxVasug24vPCzu65j1VtwXjvlKkZ1XKvbku21cCOl6THce9aRezTdT/365dCFr8EXT3C6R8/6Kw08fyzTPXkxmCKHXu569vz+9D971CTVKiLqcbn8jScricfdc1/Pay7KbYiWGsj3XM8ExFMtdX2XF4kvzvI8km6x62RvxlZp71/yPo9NUa8o+wW/OSpZcAT79esFGLTwb8F+yquoTQYwraXnVuc768PMSk8HSqXHIcf31p1dR8Cg4RSHY7gC7GWo1e59+bDa+6/6fYurmNAveVOc+E5p5A3bDq+gr5T4ttgkIYhdb/C/NmF4L+V2HuujdX8djnhtrCEy5wkeRDRNk8UiiDy2Tf6cB4J5TGLNwqNefxx0F7qeADZLkoqVXGCy3meNElYqk4CRqyxOyujwS+qNKt1lDIwSiaKdl0QEub3Y8nOQHxQQniUJJ0t+fRpIDYbk1QUoJVMXWVtclZLQr8hll/C6Zy2f3rliLlHj3bv4LWHGDsootz8FUctmrG5WxYcnyugVWJluV2xZTExZbGyMmiFxtTI1L8NdQ/k86aUx0+y/bueTTzov5jq6RyYIecVZ62aUisxPKSOf/5LmHL26mqA5d78qYF9n2v+cnW487wJSIiu5sDzfkf8v89X3w5++9NQtSDkSwt2vOkpnkt5GWX9KfvGdzMtvzsuMVXF4WaoZdfKwJqIZwdzHPvebuOpPydqQCLEkXORIsWoay7cWFErdxB390aKF8qUetkL/Cs802QbeG826IpsdFz9Wzz2bcuppvv+bN+U2EaWC2PZ0jzp7RtjFqWl21NXm+INLo9BvMzs56yLjBy9MLxI57MI3+tpZjFA0B02R6OPHrGCk7sUzf4fpA6DuXR5fUOlOEgoLggNiUkIV63mCubxU2r7HqTGrY/N8vYiZXz7bePCtrBLsGvmz4b4EclaRIFSYFZ5HAjBvp+97XcgtDtmNyshy9WUMeFJSqRTmrOpEL3oa1Y5S4cJRuMbRM20uW2VKbdgiDwGFwlpWHeTHFFKcnFUuczn1CaRP+1klSewndvkiabKdLWr046XVCV6UNyQK18k1IJ+UEKbDe69MnUuISCkgedI/ulO0FMaMt6OcGvv3nXc62ifRnHx6dSdYjM30JndXhos5Tdid/OksKX/JqHhufFj0rjSL8mGLVS3XLFgYeuU5Kek0Z58k1zCXgNLkoH1uzHbwqO9FxiJzqSIObFoWEHiuFFJ50qIpDF84wYtKwNuHhieR4s5yEwXEhI6nWu7c1kyL9Uj28tQr3JK2fWnCeY0mYnnKk370E8bZ6ltTPc1JU21Ihw6o5OfaEDLLInjPeY16e3YqPuve3pimur+khLFIgEwNVITLwwvLWLwVhvOWXFRj3/KMNB47mV3mO7mux4Nss3pKhtOrliAuO52TrTgz1CqWCULSOQ2+XNRwdtMiCn30mFhxcKIvh722ZaVivrwPghRxqChksizX/zdbVxsU73tIxL9wYWoa782fEp8w2CThFhdzgfEiCiKD4iIt09rTns2acC06c3m3KW8B9lGzxSbFuPYgyd5Gz+ngOwpXlGaUaa/LSgabF9DSPiWtwxK7XhOrDFEtU1YsEAt3FDyDbctoQ5M2XEyfFltXtUMzcb2gjQRRxanzR6pPn64eWTC/ZpiThmvmp5nXjMwXRs52pMbjNN2rPami4FB6+mIiMZRI+vBBsDQ32rn26HgrayXRboay84ly61blk86OBQAKTk0z7Oi894+VZ+p5Lu5p0y7udZLE86Y/e67mB0cXFEYF89QvXqiTOdFFhdEcoeNCLdMdnr144MncoGG6oZ48h6wNy63JVuSog9rzXTjrBBuHrQsimi+AOH7kfE6PmVlPzvnzPdlm5gBoCCwAwFjnpMaxq1ms1WONRgBAhxtNbRRcYXRVfJKCN2tF4BDiT9xFXfm9tMg6+rtFWwC2u28ILYMdPNCOPQjWw1oczWwYACwABVR/5eE4b4MI1qrZ2MlHoV9BOcZAtSMY1AVECg84Ar4vP4cAgKXlThiDTAc7oIBRuklXAxoatFSbSgAnBMhQ6YQCIkx0QkM4zHTCgDucc8ICHV45moErgroWBICAuAMX6qAeNNAIFVAG5dAMzsCBQAiCYPCPIyeDIN+MdTaLalAVTYVaKIEAYMIhqw7LaoSaUlDFBSpohNaEpWYU/ADXrC6BBzWcVAkVJeFdQQtUQ7EZg0CBXWJUQuGEfNFAG4lu2LjlxrtzliQfDjZdggVrU2B3be0iTQGq6UWhwfEXcw+6IAYhHYkAE9rhDtyxlI8GwXmjshGMDgA=

The final CSS embed then becomes:

<style>
  @font-face {
    font-family: "Noto Emoji";
    src: url(data:font/woff2;base64,d09GMgABAAAAAAsMAA8AAAAAESQAAAqzAAEAgwAAAAAAAAAAAAAAAAAAAAAAAAAAHCAGYD9TVEFUHACBRBEICpgolFMBNgIkAxYLFAAEIAWDFgcgFyQYFBs4DqOifnFSMJK/SMg2S3DvmUTRWxZzRsAlhV/3CElmD2ib94QBiKgoKVbiFHVWIGISUto4BbMGK2OJW6vLKsJYZCrodNweIR2o2i7EfwPmTVhNAwSi+9/vV30XfZh11RJIjdBI8+R87jCIaRP1RqkQkolG08TulrJpQ+rrSrYbSysQ641leOXbu3UUQAAAB0xgAZKUnCEFC8AAAIyAszQG54nMBSwANhi7GABhhRdAm0CNsiVYY1EIGkFhBk4oaG+HOflCIR/i3b6OmFcPEwpIRL4pXQZBioQCZ7AEZCKLnGgyOB5RbWXlzQiIGBDREOIeR2kmRAITDltgIBAtpuooALevXlgvyfA1sRL3iP3/+3fBVEoEwuoJoJJXfREQcCoWAWXsJfEAaEC+jUsAwDDdxx4BsIB8hwQAM0dW2COAOSA/thJMzgEZgU+WIWaLoxoBNwz7CKZKAEfUBGRhDZgiaAaTTCKltdKcSb50BtsV50Bg2VmyHGhMW48gKhFjknB4BzKdjLG1JZPxAbSRyTSEsCPyhtHI6TaZTAq9XnpoGxgwyEp1RmPkhiXIw8MNj/F5qpAieLDI/ZBeL9cZjUYEk8mEj8FgAHq9vrZrSOFsHER354AM9P0wBuWIaeioZL/U1TCAmia1t3g4/djqnnL9tClcpetst8OE33AozIubbu64nQhGnJe8x+au4Op6QCtYbhhn6j2/uygFfOulhA7TU/w953pFPaLzdc1DUNl0Gt2TJ4PyTdf0OPPSe+1NQ89K5LFhAHBYGxhka2rtvuvGWGsKW3IE5zVq2ta7YX0bRCmhVE9I7+ujzGCDAd/rfJzbmNQmq6XbJGk6SDGoiEGjz3/UL91wwMt0xc34XI3behSf7TTDwOPHef1IS5UeKRRx8+6uuYe0r8SxW3qtUd7/6kB1x4jTnWNF8aS9WUeIwRCTM24cSorWasZhFWZanYkfqmQ1IuDoQ6joamgEkxd7n16dN44pDNbpL6nkCsNO4sUwrcb2qwWy+I7n9HXxS1WZAzgVuiNgOlwsIcJ/w/lfpNHdQKDkLV3LEPcsImfLSjYepcRsylCu01bhlyvzdPYleZJda/JLhsG+S5W6Gz3XPaB/XqJEvuO5gcjdLU7vWYcz8or83A0ERlVmec9yIUXClx9PQzdSkgsOtRmN8nkjCp7UU7rdIDMYeIq+PgdhkPRCXiKHuzu9kixQoNiKIE/pOP2lOs5ZfGQyA/D3NabfMAZwX4uZ15s/jOEK42guB0O+pkwNuq0gLSIba3o6pEAEvo5Jv/+k2NO43R3ZeCZVVCzkm1Mk+daeymf3gk0+UdVtOjZaRvUgwli7Rq6QaXRZ6jtHxVasug24vPCzu65j1VtwXjvlKkZ1XKvbku21cCOl6THce9aRezTdT/365dCFr8EXT3C6R8/6Kw08fyzTPXkxmCKHXu569vz+9D971CTVKiLqcbn8jScricfdc1/Pay7KbYiWGsj3XM8ExFMtdX2XF4kvzvI8km6x62RvxlZp71/yPo9NUa8o+wW/OSpZcAT79esFGLTwb8F+yquoTQYwraXnVuc768PMSk8HSqXHIcf31p1dR8Cg4RSHY7gC7GWo1e59+bDa+6/6fYurmNAveVOc+E5p5A3bDq+gr5T4ttgkIYhdb/C/NmF4L+V2HuujdX8djnhtrCEy5wkeRDRNk8UiiDy2Tf6cB4J5TGLNwqNefxx0F7qeADZLkoqVXGCy3meNElYqk4CRqyxOyujwS+qNKt1lDIwSiaKdl0QEub3Y8nOQHxQQniUJJ0t+fRpIDYbk1QUoJVMXWVtclZLQr8hll/C6Zy2f3rliLlHj3bv4LWHGDsootz8FUctmrG5WxYcnyugVWJluV2xZTExZbGyMmiFxtTI1L8NdQ/k86aUx0+y/bueTTzov5jq6RyYIecVZ62aUisxPKSOf/5LmHL26mqA5d78qYF9n2v+cnW487wJSIiu5sDzfkf8v89X3w5++9NQtSDkSwt2vOkpnkt5GWX9KfvGdzMtvzsuMVXF4WaoZdfKwJqIZwdzHPvebuOpPydqQCLEkXORIsWoay7cWFErdxB390aKF8qUetkL/Cs802QbeG826IpsdFz9Wzz2bcuppvv+bN+U2EaWC2PZ0jzp7RtjFqWl21NXm+INLo9BvMzs56yLjBy9MLxI57MI3+tpZjFA0B02R6OPHrGCk7sUzf4fpA6DuXR5fUOlOEgoLggNiUkIV63mCubxU2r7HqTGrY/N8vYiZXz7bePCtrBLsGvmz4b4EclaRIFSYFZ5HAjBvp+97XcgtDtmNyshy9WUMeFJSqRTmrOpEL3oa1Y5S4cJRuMbRM20uW2VKbdgiDwGFwlpWHeTHFFKcnFUuczn1CaRP+1klSewndvkiabKdLWr046XVCV6UNyQK18k1IJ+UEKbDe69MnUuISCkgedI/ulO0FMaMt6OcGvv3nXc62ifRnHx6dSdYjM30JndXhos5Tdid/OksKX/JqHhufFj0rjSL8mGLVS3XLFgYeuU5Kek0Z58k1zCXgNLkoH1uzHbwqO9FxiJzqSIObFoWEHiuFFJ50qIpDF84wYtKwNuHhieR4s5yEwXEhI6nWu7c1kyL9Uj28tQr3JK2fWnCeY0mYnnKk370E8bZ6ltTPc1JU21Ihw6o5OfaEDLLInjPeY16e3YqPuve3pimur+khLFIgEwNVITLwwvLWLwVhvOWXFRj3/KMNB47mV3mO7mux4Nss3pKhtOrliAuO52TrTgz1CqWCULSOQ2+XNRwdtMiCn30mFhxcKIvh722ZaVivrwPghRxqChksizX/zdbVxsU73tIxL9wYWoa782fEp8w2CThFhdzgfEiCiKD4iIt09rTns2acC06c3m3KW8B9lGzxSbFuPYgyd5Gz+ngOwpXlGaUaa/LSgabF9DSPiWtwxK7XhOrDFEtU1YsEAt3FDyDbctoQ5M2XEyfFltXtUMzcb2gjQRRxanzR6pPn64eWTC/ZpiThmvmp5nXjMwXRs52pMbjNN2rPami4FB6+mIiMZRI+vBBsDQ32rn26HgrayXRboay84ly61blk86OBQAKTk0z7Oi894+VZ+p5Lu5p0y7udZLE86Y/e67mB0cXFEYF89QvXqiTOdFFhdEcoeNCLdMdnr144MncoGG6oZ48h6wNy63JVuSog9rzXTjrBBuHrQsimi+AOH7kfE6PmVlPzvnzPdlm5gBoCCwAwFjnpMaxq1ms1WONRgBAhxtNbRRcYXRVfJKCN2tF4BDiT9xFXfm9tMg6+rtFWwC2u28ILYMdPNCOPQjWw1oczWwYACwABVR/5eE4b4MI1qrZ2MlHoV9BOcZAtSMY1AVECg84Ar4vP4cAgKXlThiDTAc7oIBRuklXAxoatFSbSgAnBMhQ6YQCIkx0QkM4zHTCgDucc8ICHV45moErgroWBICAuAMX6qAeNNAIFVAG5dAMzsCBQAiCYPCPIyeDIN+MdTaLalAVTYVaKIEAYMIhqw7LaoSaUlDFBSpohNaEpWYU/ADXrC6BBzWcVAkVJeFdQQtUQ7EZg0CBXWJUQuGEfNFAG4lu2LjlxrtzliQfDjZdggVrU2B3be0iTQGq6UWhwfEXcw+6IAYhHYkAE9rhDtyxlI8GwXmjshGMDgA=);
}
</style>

That can be included in the existing <style /> block or a separate one.

---

Delivery size comparison

When taking gzip encoding into account (which github will use for delivery):

• The SVG is 7.6KB vs the GIF 100KB.
• Adding embedded subsetted font (with CSS content, approx 3-4 KB) only increases the SVG to <11KB.

I would argue that is still acceptable, a 90% reduction in size remains compared to the GIF asset.

Final results

This results in everyone seeing this (you could change the font if you want to use different emoji of course):

[lebensterben]

That's a pretty decent analysis.

But why the emojis are still not aligned? If they are from the same monospaced font set they should have same width.....

[polarathene]

If they are from the same monospaced font set they should have same width.....

Previous response

I don't think that font is monospace? It may be intended to be used with non-monospace fonts. Do you have one without that issue? It's a common issue AFAIK.

It may be possible that when the emoji font supports the VariationSelector modifer (allows for explicitly hinting monochrome or colour when variations are available), as this page notes.

Alternatively, you can open the subsetted font in a font editor GUI and manually ensure a common width for all glyphs.

There is non-standard usage as well in fonts patched with Powerline or NerdFonts glyphs which use the unicode PUA (Private User Area), that is non-standard though - thus should not be expected to render the correct glyph if any unless the user has the font (or you embed it). This approach is common for terminal fonts to add symbols with.

---

UPDATE: Inspected the glyphs with the crossplatform font GUI editor BirdFont (open-source). Everything looked fine there, so they are correctly monospace 😅

I went back into the browser and messed around with the generated SVG and CSS to inspect further.

There was two different x axis offsets used. Perhaps due to whatever the tooling detected when generating the SVG?:

If setting them all to 3.006 you'll get a consistent alignment output:

[mre]

Aha! So that might be something that we could report to svgterm. Maybe it's expected behavior or maybe there's a setting somewhere to fix that. If not we can always use sed in our script and add a comment about this discussion.
@polarathene, what do you think about creating a pull request based on this one which includes the fixes you found plus the CSS embed?

[lebensterben]

honestly we can see that it's not really monospaced...

every emoji is twice as wide as the hyphen characters below the "summary"....

[polarathene]

Aha! So that might be something that we could report to svgterm.

The project doesn't look like it's maintained anymore? So reporting probably wouldn't accomplish much 😅

If not we can always use sed in our script and add a comment about this discussion.

Yeah I was thinking the same.

@polarathene, what do you think about creating a pull request based on this one which includes the fixes you found plus the CSS embed?

I want to generate the SVG myself to reproduce the alignment issue.

It seems that currently with this PR you are intending to run the generation script locally, then apply the sed fix in the script comment afterwards (followed by additional changes we've noticed needed for us), and then you upload that SVG?

Looks like we could possibly automate the generation with Docker, if I get that sorted would you like to update the Makefile to utilize that?

---

honestly we can see that it's not really monospaced...

every emoji is twice as wide as the hyphen characters below the "summary"....

@lebensterben Well, one part of the issue is the SVG placement had two different offsets which caused the misalignment. I'm not sure if that was from the generation of the cast, or the project that converts the cast to SVG. It may be based on what font it used to calculate width for that caused that variation?

I've read that emoji are generally meant to be a square ratio, for monospace fonts about two widths. Each glyph in the font editor showed it horizontally centered:

The GUI app used doesn't seem to provide a width measurement, so I assume they're all the same (different levels of zoom in the screenshots, the UI is not pleasant to work with).

Anyway, as noted in my prior message, this is a non-issue for us, the SVG graphic for each has an x offset, we can just lower it from 3.006 that I used in the screenshot to shift text to the left more if that's a concern.

[polarathene]

Reproduced the rendering issue with the following:

docker run --rm -it -v "/tmp/svg:/tmp/svg" alpine ash

# Testing with the current lychee release
apk add cargo openssl-dev node asciinema pv git
cargo install lychee
export PATH="/root/.cargo/bin:${PATH}"

# Testing against the current lychee repo (note TEST.html change in this PR needs to be applied):
mkdir -p /tmp/lychee && cd /tmp/lychee
git clone https://github.com/lycheeverse/lychee .
npm install -g svg-term-cli

# Generate the SVG:
svg-term --command 'assets/screencast.sh' --out '/tmp/svg/screencast.svg' --width 100 --padding 10 --window

# Apply fixes here

[polarathene]

Providing the .cast generated from asciinema to the asciinema-player (Web) and ensuring the emoji font is available renders correctly:

And in my local terminal, it's correct (except the 3 glyphs that are using a different font due to the system choosing that one first as higher priority until I adjust that manually):

---

I have looked through the source of the svg-term project. I'm not sure why they're using React for the SVG generation, and it's a bit hard to follow.

Somewhere word.x is defined and is incorrect for the offset of the text that follows the emoji/glyph in the summary list.

There is an alternative project that does render correctly (and much faster and notably more memory efficient), termtosvg. The project is archived, but I doubt there's any difference in either project continuing to be maintained so that's mostly irrelevant. It required a few tweaks but results in:

They also had the rendering issue, but it was resolved. svg-term seems to have a similar unresolved issue.

That similarly required embedding the font and adding it to the font-family CSS, along with some additional CSS changes to adapt the same colour scheme that svg-term is using. The good thing is that termtosvg better supports such configuration and won't require messing around with commands afterwards to modify the document, we can supply a template file which is much nicer.

It will need some additional work to add in the padding, and if you want the window frame that svg-term adds, just let me know.

svg-term is also generating smaller filesizes due to using unicode characters directly (like the progress bar), while termtosvg is using a different approach to reference the codepoint in text (uses more bytes). That might be possible to adjust, SVGO needs to be run separately to apply SVG optimizations as well, but svg-term wasn't much better in that regard due to using a very dated version of SVGO 😅

---

Regarding feasibility for CI, you'd not get reliable diffs due to the command script having a random delay method which doesn't use a seed for deterministic / repeatable sequence of "random" delays. So you'd still want to manually generate for updates when you know the output has changed.

[mre]

Thanks @polarathene for your thorough analysis.
Some remarks below. (Not in order.)

There is an alternative project that does render correctly (and much faster and notably more memory efficient), termtosvg. The project is archived, but I doubt there's any difference in either project continuing to be maintained so that's mostly irrelevant.

Agreed.

It required a few tweaks

Can you list the tweaks here for documentation? I'm assuming you meant the following:

• embed the font
• add in the padding
• add the window frame that svg-term adds (I quite like it)

Note, for running the script, openssl-dev or similar package is needed (at least for cargo install lychee), as is pv and asciinema.

We should add these dependencies to the documentation or, even better, to a Github action that renders the SVG demo. We can do that at a later point in time, though. Come to think of it, we could even wrap all of that work into a separate Github action for SVG-based demos. It would take a script with commands as an input and render an SVG from it. That's just an idea if someone is looking for a fun hobby project. 😛

Regarding feasibility for CI, you'd not get reliable diffs due to the command script having a random delay method which doesn't use a seed for deterministic / repeatable sequence of "random" delays. So you'd still want to manually generate for updates when you know the output has changed.

We could make it deterministic by hardcoding the delays. I don't think that anyone would necessarily care or even notice.

@polarathene, @lebensterben, what do you think about merging this PR as is? We could move termtosvg as well as apply the fixes we discussed in a separate pull request. Sounds good?

[polarathene]

Can you list the tweaks here for documentation? I'm assuming you meant the following:

I would have to read over what I said here, and if I missed anything there's a chance I documented it elsewhere before I had a powercut take out my WIP containers and /tmp storage 😅

If not then I can probably recall by going through the process again. I think there was some CSS edits which I'm hoping I saved (I recall porting over the theme colours, and maybe something else..). I also remember I was wanting to provide a Dockerfile for easy reproduction of the cast and SVG.

But yes all three of those things were necessary too.

We should add these dependencies to the documentation or, even better, to a Github action that renders the SVG demo.

That'd be pretty cool, and not require the Dockerfile in this project :)

We could make it deterministic by hardcoding the delays. I don't think that anyone would necessarily care or even notice.

Sure. I had made a little utility that rounded the timestamps from the asciicast recording to a specific framerate.

Updates aren't that important since it's just content, the diff for SVG updates could just be ignored with .gitattributes treating SVG as binary 👍

what do you think about merging this PR as is? We could move termtosvg as well as apply the fixes we discussed in a separate pull request. Sounds good?

Yeah that's fine. I did want to resolve the improvements here, but due to the data loss event and a busy month that'll have to come later. I should have time later this month or next to make a contribution 👍

[lebensterben]

We can merge this PR.