Typography

[virtualritz]

At the moment, inlyne has fairly bad typography. And I mean that in a very caring way.

Caveat -- I studied typography and worked in this area for years (incl. font design). As such my sensitivities may seem extreme to you, But I assure you, they're all valid still. 😁

Issues:

• #Top Header level uses underline but the underline goes through the descenders of letters like lowercase g or y. Either make the underline have nice breaks at descenders or don't use an underline if the resp. renderer doesn't support such a feature.

• Code/monospace rendering (stuff in backticks `...`) uses automatic ligatures.
  I.e. a word like ffigen renders as ffigen. That's an absolute no-no. The whole reason of using backticks is to say: I want all of the following to be on a grid. Every single letter.

• Font used for code/monspace is optically smaller than font used for body/main text. Either use a font that renders at same size for capitals and lowercase letters or adjust the font size of either to match.
  Lowercase letters should dominate here. If your monospaced font of choice can't be well matched for both, choose a size that makes the lowercase letters match in size with those of the body/main text font.

  • Font used for code/monospace is thus too light (stroke width) for body/main text font. Even with the monospaced font used atm, fixing the size will likely fix this too. But also see next point.

• Font used for code/monspace has serifs, body/main text font is sans-serif. Select one or the other and be stringent.

• Spacing around code/monospace blocks: use a space from the monospace font before/after, not a space from the proportional body/main font. The latter will look 'squeezed'.

• Indentation of lists. Top-level lists are indented one level already. Don't.

• Color scheme for code segments is too low contrast, particualry on the light theme. Comments are barely readable on either dark or light themes.

Suggestions:

• Use a baseline grid: a baseline grid makes a document easier to read. A paragraph break is then either:

  1. A full line height.
  2. No vertical gap at all and the beginning of the next paragraph is indented (but never the first paragraph of a block)

  A baseline grid commonly uses the line height of the body text. For example, your body text is 14pt with a line height of 18pt. Everything is now typset with a baseline snapped vertically to an integer multiplier of 18pt (everything = every element on the page, headers, code blocks etc.).

[CosmicHorrorDev]

Thanks for the issue. I really appreciate all of the insight

I believe I agree with all of your points. Some of them should be pretty easy to address, while others will require a lot more work, but definitely good to have a better idea of the direction to go in nonetheless

[virtualritz]

I would also have a simple and pragmatic suggestion.

Use the Fira font family. Fira Sans is a sans-serif (as the name suggests) and has Mono(spaced)/Code variants with different weights that all match. I.e. it solves already some of the issues mentioned above.

But most interestingly, Fira has some of the broadest unicode code point coverage of all the free fonts.

And last but not least, it also has some character 😉.

P.S.: The Fira Code variant, when used, should limit the use of ligatures to the code ones, i.e. stuff like != rendering as ≠, and exclude ligatures as the aformentioned ffi becoming ffi.
But I would put use of those behind a flag/config option, possibly per language, and only use in code blocks marked as such.

[CosmicHorrorDev]

That's reasonable. We can have an optional feature that bundles the fira font family into the binary and defaults to that. I know there are some crates that support the bundling part already

[virtualritz]

I did it for my glyphana tool. I.e. embed a compressed version of the OTF.

[virtualritz]

Specifically it uses include_flate.

Something like:

flate!(pub static FIRA_SANS_FONT: [u8] from "assets/FiraSans-Regular.otf");