Skip to content

Add the xkcd-script-mono#75

Draft
dummy-index wants to merge 2 commits into
ipython:masterfrom
dummy-index:feature/monospace
Draft

Add the xkcd-script-mono#75
dummy-index wants to merge 2 commits into
ipython:masterfrom
dummy-index:feature/monospace

Conversation

@dummy-index

Copy link
Copy Markdown
Contributor

Closes #37
Automatically collects glyphs close to 0.6em in width.
We will continue to consider the choice of glyphs.

@pelson pelson left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! Very exciting! 👍

I think we need to be careful with the pipeline as part 6 in particular tweaks the normal font extensively - those tweaks will want to be different for the mono form.

Perhaps we can use the normal font as the basis for the mono font, swapping in whatever we need to make it look correct? If we take that approach, we simply need to add a stage 9 (or put that at stage 9, and make the final stage work on both). If we can't use the normal font as the basis, then I think we need to be careful to avoid too much branching in pt6 in particular. It maybe that we should have pt6 know that it produces 2 fonts without us passing that as a parameter and calling it twice will at least give us less variance on the "bodyname".

Finally, to proceed, I think we should get to the point where you can submit this without any change to the normal font - that means pulling out whatever we need into a separate PR for the normal font. For the mono, we should have PR which produces suitable samples (Ipsum Lorem if necessary, but perhaps better to have a code snippet or something) so that we can start from the very beginning to have a visible diff as the font evolves.

['dflt']]]]])
font.addLookupSubtable('ligatures', 'liga')

c = font.createChar(-1, ".notdef")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a very useful addition even without the mono?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, these are things that need to be added according to the OpenType specification. Even if they are not present, they are automatically added when outputting to TTF, but those glyphs break the conditions of a monospace font. Hmm, I’ll change it to a square + question mark that meets the standard and submit a PR.

c.simplify()
c.round()

for line, position, bbox, fname, chars in characters:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for the non-mono form too?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, lines 343 to 351 remain as before; it's a loop that converts all SVG files into glyphs, and glyphs with the same name are overwritten so that only the last one remains. Oh, that means at that moment, since the glyph exists, I can just copy and paste it into *.mono.
By the way, I don’t like writing things like ' + 60 * _line_fgs / 856' twice, so I want to reconsider the method for listing monospaced glyphs.

@dummy-index

Copy link
Copy Markdown
Contributor Author

thx!

swapping

Hmm, if the width of the glyph you want to replace is different, you can't really reuse the positional relationship between the top marker and the topright marker, right? Or if the mono glyph already has appropriate markers attached, that means it was done in stage 7.

separate PR for the normal font

I see.

  • Add notdef etc.
  • To be able to distinguish between I and vertical bar (this should be the role of stage 6)

@dummy-index

dummy-index commented Jun 12, 2026

Copy link
Copy Markdown
Contributor Author

As expected, even if I replace the body reference of accented glyphs at stage 9, the position of the accent doesn't follow. It's not impossible to fix each one systematically, but I really don't want to do that.
So "we can't use the normal font as the basis". The base font has about one set of the basic Latin alphabet, and from that, you build accented letters. (Or do you make everything from A.mono to Agrave.mono and so on? In the end, it ends up being like running pt6 multiple times.)

give us less variance on the "bodyname"

Okay

  • xkcd-script-mono-ptX.sfd will branch at the end of pt5 instead of the beginning of pt6. We'll handle things like fontname in pt5 and just not worry about them in pt6.
  • It might be fine for the IJ to let the serif of J stick out dramatically… If we make it ourselves, we’ll temporarily name it IJ.mono and use it to replace IJ in pt8X. (We might even want to use it on the base font side too.)
  • We'll also delete other unused kerning tables in pt8X.In pt7, it checks inside the .sfd file to decide if kern is unnecessary, instead of using the bodyname given from the command line.
  • "pt8b_output_monospace.py" will outputs ../generated/xkcd-script-mono-pt8.sfd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

xkcd monospace

2 participants