Default figures should be proportional - like v1

[kenmcd]

Today I was looking at some sample text I had created for Junicode v1 - and it looked wrong. The dates all looked bad. So upon investigation I discovered the default figures are now tabular lining. In v1 the default figures are proportional lining (which makes more sense). So anyone moving from Junicode v1 to Junicode v2 is in for a shock.

I do not see Junicode as some office suite utility font. Tabular lining is appropriate in that case. But Junicode is for replication/transcribing of old long-form text. At a minimum the default figures should be proportional, and probably the default should be oldstyle proportional.

In long-form text I always use oldstyle proportional figures, which is the best thing for high-quality text - it is what you are going to see in high-quality books. So I usually have to set-up a character style to fix the dates, etc. Today I had to use Junicode:onum&pnum in LibreOffice to get text quality figures.

Many high-quality text fonts have oldstyle proportional as the default figures. When you are writing a lot of long-form text why should the writer constantly have to "fix" all the figures?

Some OFL Google fonts with oldstyle proportional as default: Alegreya Alegreya Sans Coelacanth Garamond Cormorant EB Garamond ... (I just started down the list) Playfair (he told them No) and many more.

And lots of fonts in Google Fonts have proportional lining as the default. They like to have tabular lining as the default, but many fonts just say No. In many cases it just does not make sense.

Given the target use of Junicode I would make the default figures oldstyle proportional. But at the very minimum I think you should go back to proportional lining as the Junicode v2 default figures.

Note: there are also a number of commercial fonts with oldstyle proportional as the default figures - usually marketed as high-end text fonts.

[psb1558]

Proportional lining figures have never been the default in Junicode, but always tabular lining. Do you have your software set to apply pnum as the default?

That said, it's a fact that almost every time I set up a document, I turn on pnum and onum, and it's true that figures in the kind of document that Junicode targets are most likely to appear in a prose context. If it's not too disruptive to existing users, I'll change the default to proportional oldstyle in the next release.

[kenmcd]

Great. I suspect we are not the only users who do this. And this will be a welcome change to most users.

Hmmm... will check again tomorrow, but I think I was looking at the last v1 in FontCreator (where I typically check OpenType stuff).

[Doc73]

Sorry for this post, but in XeLaTeX at least it seems that the default for this font is lnum+tnum. I am a fanatic user of onum, but I think it would be more prudent to set lnum+pnum as the default settings.

% !TeX TS-program = xelatex
% !TeX encoding = UTF-8
% !TeX spellcheck = it_IT
% !TeX root = Junicode-numbers.tex

\documentclass[11pt,b5paper,article]{memoir}
\usepackage{fontspec,unicode-math}
\setmainfont[]{Junicode}
\ExplSyntaxOn
\NewDocumentCommand{\extractfont}{}
 {
  \str_set:Nx \l_tmpa_str { \fontname\font }
  \regex_replace_once:nnN { \:.* } { } \l_tmpa_str
  \regex_replace_once:nnN { \A \[(.*)\] \Z } { \1 } \l_tmpa_str
  \regex_replace_once:nnN { \.[^\.]* \Z } { } \l_tmpa_str
  \regex_replace_once:nnN { \" } { } \l_tmpa_str
  \regex_replace_once:nnN { /OT } { } \l_tmpa_str
  \regex_replace_once:nnN { \[|Regular|Roman } { } \l_tmpa_str
  \str_use:N \l_tmpa_str
 }
\ExplSyntaxOff

\usepackage{hyperref}

\begin{document}
\begin{table}[h]
  \caption{Font \extractfont}
  \begin{tabular}{lll}
    1234567890 & default & lining+tabular?\\
    {\addfontfeatures{RawFeature=+lnum}1234567890} & lnum &
                                                            lining+tabular?\\
    {\addfontfeatures{RawFeature=+tnum}1234567890} & tnum &
                                                            lining+tabular?\\
    {\addfontfeatures{RawFeature=+pnum}1234567890} & pnum &
                                                            lining+proportional?\\
    {\addfontfeatures{RawFeature=+lnum;+pnum}1234567890} & lnum+pnum &
    \\
    {\addfontfeatures{RawFeature=+lnum;+tnum}1234567890} & lnum+tnum &
    \\
    {\addfontfeatures{RawFeature=+onum}1234567890} & onum &
                                                            oldstyle+tabular\\
    {\addfontfeatures{RawFeature=+onum;+pnum}1234567890} & onum+pnum &
    \\
    {\addfontfeatures{RawFeature=+onum;+tnum}1234567890} & onum+tnum &
    \\
  \end{tabular}
\end{table}
\end{document}

%%% Local Variables:
%%% coding: utf-8
%%% mode: latex
%%% TeX-engine: xetex
%%% TeX-output-dir: "junicode-numbers"
%%% TeX-master: t
%%% End:

[psb1558]

I've never been very fond of proportional lining numbers. Seems to me the only place they make any sense is in an all-caps context, and how much of a typical project is all caps? I'm still leaning towards proportional oldstyle as the default.

[Doc73]

Ok! For me proportional+oldstyle is fine as default. :+1:

In the meanwhile, I tested other fonts with previous MWE. Here are the default settings:

• Brill: oldstyle + proportional
• Minion Pro: lining + tabular
• Libertinus Serif: lining + tabular
• EB Garamond: lining + tabular

P.S.: in previous MWE I added some stuff to print font name in pdf.

[kenmcd]

Seems to me the only place they make any sense is in an all-caps context

Quite a few fonts include proportional lining figures in their Case Sensitive Forms case feature. For example: Playfair - the default oldstyle proportional is converted to lining proportional when case is applied STIX Two Text - converts their default tabular lining, and oldstyle figures to proportional lining when case is applied. Alegreya - case converts figures to proportional lining Cormorant Garamond - case converts figures to proportional lining Literata - case converts figures to proportional lining Merriweather - case converts figures to proportional lining Noto Serif - case converts figures to proportional lining Source Serif 4 - case converts figures to proportional lining and many more...

You are not alone in the opinion that proportional lining figures are appropriate in all-caps text. So you may want to add that to the Junicode case feature.

[psb1558]

Lining figures have been in case for a while (I'm not sure how long--don't remember when I added those rules).

case and a number of other features are touched by this change: sups, subs, frac, zero . . . I'm hunting them down right now. It will have to be tested carefully.

[kenmcd]

Regarding the one style in the oldstyle figures:

A few "old style" fonts who are trying to stay true to their roots use the old style one (which looks like a short capital I). Most newer text fonts use the more modern flagged one (which looks like a short one). Some fonts give users the option of using either form.

Old style one as default in oldstyle figures: Cormorant Garamond EB Garamond

Modern flagged one as default in oldstyle figures: Alegreya Besley Bookmania (commercial) Crimson Pro Georgia Pro (commercial) LibreCaslon Text Literata Merriweather Noto Serif Palatino (commercial) Playfair Source Serif 4 STIX Two Text

Grad (commercial) - default is old style, modern style is ss02 Vollkorn - default is old style, modern style is ss11 XCharter - default is old style, modern style is cv01 and I have seen quite a few others which give users the option.

For my use, I would prefer the modern one as the default in the oldstyle figures, because I am writing modern text not transcribing old text. But the old style one may be more appropriate as the default one in the oldstyle figures for the Junicode target audience of "medievalists" who may prefer that old style one. Dunno. Leave that one up to you. But it would me nice if both versions of the one were available in the oldstyle figures.

Which form do you see most often in old text?

[kenmcd]

Lining figures have been in case for a while (I'm not sure how long--don't remember when I added those rules).

Hmmm... I am not seeing this being applied when testing in FontCreator OpenType Designer. I was just turning case On and Off and saw no effect on figures. But now looked closer and I can see the feature there - but nothing happens. Have to investigate further...

Update: case not working on figures in LibreOffice either.

Update: and the normal stuff like (){}[]-@$& etc. which would normally be in case is not there. Just osf figures (which do not work) and a bunch of marks. We should move this case discussion to its own issue. I will open a new issue after I have messed with it some more.

[kenmcd]

The oldstyle zero.osf and zero.tosf need some contrast like the normal zero. It looks odd as simple ring.

[psb1558]

Fonts differ here. In the model for Junicode, the zero is a simple ring:

In Adobe Garamond, which was influential with me back in the day, the zero is a nearly perfect circle, and not only is there no contrast, there's not even optical correction of stem weights. Plus, the weight of the zero is not made to match that of other figures:

I believe this aspect of the Adobe font is historically accurate, though it is a little jarring. Less historically oriented fonts (e.g. Brill, Libertinus) do not tolerate this, but weight the zero like the other figures.

I thought about this many ages ago, when I was designing these numbers, and decided to stay with the old style, but do optical correction (unlike the Garamond):

I'm still comfortable with this choice.

[psb1558]

In old books the one is, I believe, always I-like. I've been meaning to add the flagged form as an alternate for some time. Perhaps this is the week it gets done!

[psb1558]

All the number features are getting reviewed and revised now. I'll make sure the case feature is working properly as part of this process. But in the ordering of features, case comes before pnum, onum and the others, so it will be entirely possible for the (new) default to become a lining figure with case, and then for pnum and onum (if they are on) to change it back to the default.

[kenmcd]

I believe this aspect of the Adobe font is historically accurate, though it is a little jarring. Less historically oriented fonts (e.g. Brill, Libertinus) do not tolerate this, but weight the zero like the other figures.

Perhaps add an alternate with contrast for users writing modern text. In a normal context (not historical text) it is "jarring" and the font looks broken. I was not aware of this old format and to my non-medievalist eye it just appears wrong. Same issue I suppose with the ring on the Aring in some fonts. Just looks odd in normal text.

[psb1558]

Maybe I could put the zero on the same OT feature as the flagged one. ssNN and cvNN features are getting kind of hard to come by. Or maybe there's some suitable number-specific feature I haven't noticed yet.

[kenmcd]

ss21 is open. < grin >

[psb1558]

Last resort.

[psb1558]

Actually, ss09 is also open. I was reserving it for language-specific variants, but in practice it has proved a better idea to create language-specific variants within other features (ss02 behaves differently depending on whether the language is English or Irish—there may be more like that in the future).

So ss09 might be perfect for "Alternate Figures." Are there others I should be thinking about?

[kenmcd]

So ss09 might be perfect for "Alternate Figures." Are there others I should be thinking about?

Have a few ideas. Will also look at some "it has everything" fonts. Will not be at my computer for an hour or so. On my phone at the moment.

[psb1558]

Here's a first go at flagged one:

1. proportional oldstyle (the default)
2. default + ss09
3. default + ss09 + tnum

[psb1558]

And zero. The proportional and fixed-width zeroes are the same, but every style of zero in Junicode needs a slashed version.

[kenmcd]

Here's a first go at flagged one:

1. proportional oldstyle (the default)

2. default + ss09

3. default + ss09 + tnum

The flag seems a bit long and thin. I like to see the one as a shorter lining proportional one, but optically adjusted for the size. Flag a little shorter and a little thicker (esp. at the base). Serifs a little thicker. Sort of the same way the one superscript would be optically adjusted for the downsize.

zero looks perfect. How does it look with the 8? Do the sides look the same weight, or should they be thinner?

[psb1558]

The oldstyle ones in the fonts I surveyed almost all had flags wider than the serif (sometimes extravagantly so), e.g.

That also struck me as a little odd at first, but I think I understand the design problem it addresses: it's hard to make a one fill the space it needs to fill—especially, but not exclusively, the tabular form.

I'll work on the weight of the flag and serif.

[psb1558]

This time the flag is a tiny bit shorter, but mainly it's significantly thicker. Maybe that makes it look a little shorter too.

[kenmcd]

This time the flag is a tiny bit shorter, but mainly it's significantly thicker. Maybe that makes it look a little shorter too.

I like it.

[psb1558]

I've posted variable fonts (only) with the changes we've been discussing in the fonts directory (no release yet). Since these changes are substantive and highly visible, I'm bumping the version number to 2.100 (for now followed by RC numbers). Here's a summary of the changes:

• proportional oldstyle figures now the default.
• use lnum to get lining figures, tnum for tabular (fixed width).
• ss09 produces alternate shapes of oldstyle zero and one (including super- and subscripts and slashed zero).
• in super- and subscripts there are (as before) only proportional oldstyle and tabular lining forms.
• in fractions there are only tabular lining forms (but I am thinking of adding proportional oldstyle).

The number system is suprisingly complex, involving over 200 glyphs and at least twelve OT features. Lots of opportunities for me to make mistakes. So I'll be grateful for any checking that folks can do.

[kenmcd]

OK. Really like having oldstyle proportional as the default.

Started looking and testing...

Expected the Oldstyle Tabular and the Lining Tabular to be the same width (as in other fonts). The Oldstyle Tabular seems really wide (loose).

[kenmcd]

Oldstyle Flagged One Spacing and Kerning This is the Italic. For example in the GIF below the one appears to be a bit too far from the two - it does not have that top-right serif to make it look closer. And the two ones in 1811 appear to be a bit loose. The Roman has some similar issues. Perhaps take a look at the spacing/kerning on both sides of the flag one.

Kerning is On in this test.

[psb1558]

Thanks for these pointers. I think I see what to do. Will report back.

[psb1558]

Another go at revised numbers in the repository. I confess that I've never taken numbers seriously enough--never thought of them as a system as opposed to a collection of (somewhat boring) isolated glyphs. Now I'm taking care of that. Also some of the outlines are seriously in need of revision, and I'll be addressing that before I make another release.

[psb1558]

Okay, version 2.100 RC 3 is now in the repository. Most of the work here has gone into making sure tabular figures are always the same width and there is consistency of size and positioning across the font. Also a certain amount of outline revision.

You can get superscript and subscript numbers in either of two ways: applying sups or subs to plain numbers or entering the Unicodes for superscripts and subscripts. Either way, the number features affect these characters in a limited way. Use lnum to shift from oldstyle to lining numbers--but pnum and tnum have no effect on superscripts or subscripts.

[kenmcd]

v2.100.RC3.(2023-09-25).from.repo

That looks really good.

Will do some more feature testing tomorrow. Kinda fading now...

[kenmcd]

Please consider more adding more currency symbols to Oldstyle.

Junicode 2.100.RC3

STIX Two Text

Cormorant Garamond

[psb1558]

Yes. An excellent idea.

[psb1558]

This is going to take a little while, but here's a downpayment.

[eclecticfluff]

I don’t currently have the most recent version of the font so sorry if it’s already there, but the percent sign could probably also do with a short Oldstyle form.

[psb1558]

This, and also numbersign. Am I missing anything else?

[eclecticfluff]

Test pdf The primes and single quote and degree symbol are too high, but there are other contexts like °C where they should not be lowered. The period and comma alongside the aforementioned symbols could do with having kerning pairs in numbers since presently they leave unsightly gaps. Lastly, while the plus sign looks perfect and most of the others fine, the minus sign is noticeably longer and higher than the equals sign. It seems to have the same shape as the en dash, so maybe both could be lowered and length shortened only on the former. Also, while I didn't include it, ‰ and ‱ could be modified alongside %. I hope helps with the number overhauls and isn't too daunting of a list.

[psb1558]

No, it's good. Thanks for taking the trouble!

[psb1558]

There's still lots to do (hinting, kerning, the italics) before release, but I think maybe this answers.

quoteright, degree, and endash are contextual: you get the lower form of the first two when an oldstyle number precedes, and of the third when an oldstyle number both precedes and follows. The others are controlled by OT features exactly the way the figures themselves are—with lnum, tnum, etc.

[eclecticfluff]

That looks like a great start, but there are a few more contextual cases which should be considered. Prime should probably also vary contextually considering its use with letters. Also, quoteright needs some rather complicated contextual rules since it needs to work in the cases of 1’000, ’23, 2020’s, P’s, q’s, ‘quoted text 1’, and ‘1’000’. The distinction between elided digits and quotation marks becomes unsolvable once taking into account languages where the opening quotation mark is also quoteright.

[psb1558]

Prime has lots of uses (math, linguistics ...), probably too many possible contexts to make a reliable rule for it. As it is now manually switchable, so that users can always get exactly what they want, perhaps it would be best not to try.

I'm now handling minus, quoteright, degree, and endash via substitutions, but it seems to me that contextual kerning is a better solution. I recognize the problems with quoteright: the question is how many cases to handle via contextual rules and how many to leave to the user (e.g. by placing a formatting mark before the quoteright). Queries:

• should the quoteright be lowered before an oldstyle number as well as after?
• would it be useful to suppress kerning in a sequence where a comma or period follows the quotation mark, e.g. 1’.?
• If adequate contextual rules for quoteright can't be formulated, would it be better to make it manually switchable and leave the problem to users?

[psb1558]

I haven't actually located a font that bothers to adjust quoteright contextually.

[eclecticfluff]

I wouldn’t be opposed to not bothering to adjust the raised punctuation contextually, and instead compromising between the two height extremes. While it feels fine for quotation marks to sit above the adjoining text, to my eye the apostrophe looks odd when not going below the highest points of the adjoining characters. Quotation marks and apostrophes should probably always be kerned to what they are modifying, thus ’0 would be kerned and in the case of ‘0’, the closing quote would be kerned tightly to the zero, but and low punctuation kerned looser. Note that I am no typographer, and wouldn’t be opposed to leaving the heights of raised punctuation alone if no other font bothers.

Unrelated, but in the specimen you provided, I think you put spaces after the thousands separators. There’s not supposed to be any separation, the present lack of kerning around the oldstyle 4 just makes it look that way.

[eclecticfluff]

Thinking on the case of the lowered apostrophe, I think a different lowered form would only work if used solely when intended as a thousands separator (which is a simple and consistent rule). The other cases also occur with lower case letters, so making the text harmonious by manually picking the hight per quote would be hard enough, let alone attempting anything automatic. A stylistic set to lower raised punctuation font-wide couldn’t hurt if you haven’t run out of those since such cases are probably a matter of taste anyways. Also, the rule for degree needs to be refined slightly as the form 32°C is sometimes used.

[psb1558]

I've been thinking for a long time about lowering the quotation marks (some fonts I admire, like Brill and Roboto Serif, have them about even with the tops of the capitals). The project is a bit daunting, since all the kerning pairs (over 500 of them!) have to be reviewed, but now it seems necessary . . .

[eclecticfluff]

Before committing to something so drastic, I wouldn’t mind seeing how the current high quoteright looks like when kerned properly to the proceeding and following digits.

[psb1558]

This image shows the oldstyle proportional numbers with a general rule applied (that is, a quoteright both preceded and followed by a number is shifted right by 25 font units):

But then there have got to be exceptions to the general rule, as you can see with sequences like 0’8, 7’0. Pair kerning won't work here: each exception needs its own contextual rule. You can see this with the sequence 1’0, which looks bad with the general rule (below left). But you can't fix this with a rule for the sequence ’0, because that would mess up the sequence 0’0, which looks okay (or at least good enough) with the general rule (right). So 1’0 gets its own contextual rule (middle—the only exception I've put in the font so far).

The same sort of thing will have to be done with the period and the comma. Before I have gone much farther with this kerning project, I'm going to consider myself committed to the newly positioned quotation marks in the font.

[psb1558]

Some fine-tuning to do, but it's not too bad!

[psb1558]

Actually, it doesn't appear necessary to do contextual kerning for periods and commas. Big relief.