Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typography #306

Open
virtualritz opened this issue Apr 7, 2024 · 5 comments
Open

Typography #306

virtualritz opened this issue Apr 7, 2024 · 5 comments
Labels
C-enhancement Category: New feature or request

Comments

@virtualritz
Copy link

virtualritz commented Apr 7, 2024

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.).

@virtualritz virtualritz changed the title Typograpy Typography Apr 7, 2024
@CosmicHorrorDev
Copy link
Collaborator

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
Copy link
Author

virtualritz commented Apr 7, 2024

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 .
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
Copy link
Collaborator

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

@CosmicHorrorDev CosmicHorrorDev added the C-enhancement Category: New feature or request label Apr 8, 2024
@virtualritz
Copy link
Author

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

@virtualritz
Copy link
Author

Specifically it uses include_flate.

Something like:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants