Template talk:font

fields

I think adding "monospaced" would be a good idea, and the ucsur, ligature and cartouche graphic should 1) link to articles instead of the file and 2) get some space above and below. Hmm should I also add "long pi"? Jan Ke Tami (talk) 00:14, 4 November 2023 (UTC)

Ok, I'm pretty happy where this is now, but there is one open question: Should there be a feature field for glyph combinations? I'm a bit torn on this. On the one hand, it definitely is a popular feature, for sure. On the other hand, I wouldn't know how to use this field for the fonts we have. There's a very wide range of what fonts allow. Some have less than a handful of allowed combos. Some have combos based on specific base glyphs. Some technically support all combos, but they don't align well and they can't be said to all be intended for combinations. So far, only 2 fonts (nishiki teki and linja sike) really have what I'd call a "complete" combo feature where all combinations are "clean"... I don't know which one of these should and shouldn't get the combo field.

(Unrelatedly, if we add that field, that also means I'd want 2 more additional fields added so that the images align =D =D =D But what can I add?) Jan Ke Tami (talk) 19:58, 5 November 2023 (UTC)

New images

Ok, so the great thing about the new images is that they're more uniform and easier to integrate into an infobox. But there are some downsides: They're less recognisable from a distance, they rely on text that might be a bit hard to read. Because all of them take up the whole width of the cell, they also take up more space overall.

I also think they're more boring =P which you'll forgive me for saying this with all my bias as the one who made the original, much more fun, graphics =D

I also have some issues with some things in the individual images, but I'll address my concerns in their file discussion pages. Jan Ke Tami (talk) 12:09, 4 December 2023 (UTC)

rangestart

Ok I'm not really happy with this field. I do want to have something like this, but if it's to compare fonts, it'll be misleading: Ideally it would just show where aa is - and if the alphabetical order started with almost any other word we wouldn't have an issue, but many fonts just encode aa as the lowercase Latin "a" while the words that aren't a one-letter word tend to be neatly in their own block. So some fonts start their sp block with aa and others start it with akesiakesi. Jan Ke Tami (talk) 10:49, 24 December 2023 (UTC)

What could be solutions? I could note the range of the continuous pu block (seems kind of hacky, but less hacky than the current solution). I could give "families" of fonts sharing codepoint ranges a name (what kind of names would that be, though). I could point to the chronologically first font to use these codepoints (might give me some weird edge cases; and what do I do with the first font, leave the field empty or fill in the font's own name; what if there are fonts that don't have a clear chronology - still, might be the most elegant solution). Jan Ke Tami (talk) 11:58, 24 December 2023 (UTC)