Re: Auto selecting optical sizes for a font

[Hans Hagen <pragma@wxs.nl>]

On 6/25/2013 6:16 AM, Andres Conrado Montoya wrote:
> Thank you so much, Hans. :) It works great!.
>
> I must agree, however, with Georg's considerations. I am very grateful
> for the current solution, but an automatic selection of optical sizes
> could be insanely good, from a book designer point of view (I'm a book
> designer). Just for the curious, these are some links that go deeper
> in the theme of Optical Sizes for Typography:

Optical sizes have always been part of tex (macro packages) and are also 
one of the reasons why tex font subsystems are complex:

- fonts often provide only some styles / variants in sizes, so fallbacks 
need to be supported
- names are highly inconsistent, so there is no systematic robust 
solution that automates it
- only a few fonts provide optical sizes and the whole font machinery 
must not suffer (in performance) from this
- fonts can be combined in any way with other designs (and we also need 
to take math into account)

Now, the only case where optical sizes are really robustly implemented 
is in open type math as there the shapes are in one file and by opening 
this one file one gets all the information: no need to analyze names and 
whatever and deduce if/where the other sizes sit. The alternative set 
can have a smaller repertoire too.

This is more complex when sizes are spread over fonts. One cannot rely 
on the names of files (name8whatever vs name05whatever vs namewhatever4 
etc) so one has to analyze the font son the system but often internal 
names in the font also suffer from this. Then there are combinations of 
'bare name' (should have no number in it), weight, width, style, 
whatever and again this is not guaranteed consistent.

You really don't want to know how much time went into figuring out a 
decent way to analyze fonts on the system and make sure that users at 
least with a certain degree of certainty can use a 'name:' or even 
'spec:' locator. Personally I *never* use font names but only trust 
filenames because i don't want to be surprised by an updated where 
internal names changed and (in automated flows) fonts sort of dissappear 
due to this. And, the designsize feature combined with lfg files 
guarantee me that I can still use designsizes then (after all, texies 
expect lm designsizes to be supported).

So, back to optical sizes. As said, they are supported. If one has the 
goodie file (will be in next upload) and asks for the eb bodyfont in the 
way demonstrated in the typescript size matching logic will be applied. 
But in a controlled way, so you know what you get. But nevertheless it's 
automatic then. (In your sample code you used some size key, in context 
we specify that we want to use designsizes so it all boils down to 
specifying anyway.)

Any further automation will only make things worse: nothing is as 
frustrating as fighting built in cleverness. Now, I'll not go into 
details to much about eb (which is a nice font btw) but the fact that in 
a font file there is mention of a design size range is nothing special: 
many fonts in my texmf-fonts tree have such ranges and most of them have 
only one optical size, so one thing a selector then has to figure out 
is: are there more. And of course there are, if you look at some 
properties, because of inconsistent naming and tagging as mentioned, 
following some logic, all kind of antykwa fonts suddenly could end op in 
a pool of optical sizes but they are in fact all different in specific 
properties. The same is true for more fonts. So what should one look at? 
The filename: no universal system behind it. The font name? Idem, some 
have a number (size) in it some haven't. Qualifiers like Italic Ital Ita 
are all used mixed. Some fonts have extra flags? But often these have 
weird values so one cannot rely too much on it.

We see things like

  ["design_range_bottom"]=0,
  ["design_range_top"]=94,
  ["design_size"]=80,
  ["encodingchanged"]=0,
  ["extrema_bound"]=0,
  ["familyname"]="EB Garamond 08",
  ["fontname"]="EBGaramond08-Italic",
  ["fontstyle_id"]=2,
  ["fontstyle_name"]={
   {
    ["lang"]=1033,
    ["name"]="Italic",
   },
  },

and

     ["compatfull"]="EB Garamond 08 Italic",
     ["family"]="EB Garamond 08",
     ["fullname"]="EB Garamond 08 Italic",
     ["postscriptname"]="EBGaramond08-Italic",
     ["preffamilyname"]="EB Garamond",
     ["prefmodifiers"]="08 Italic",
     ["subfamily"]="Italic",
     ["uniqueid"]="FontForge 2.0 : EB Garamond 08 Italic : 2-1-2013",


So how is a system supposed to know to look for EBGaramond12-Italic or 
EBGaramond4Italic or whatever. Some heuristics have to be applied and as 
I mentioned in an earlier mail, I played a bit with it and although I 
can make you happy by supporting EB sizing automatic (of course with 
toms way to disable it) another user will be bitten by false matches and 
missing ones for other fonts (hard to trace).

To be honest: I'd already given up on fonts and names and whatever being 
systematic and logic etc ... Just as I've also given up on open type 
guaranteeing consistency or open type math taking care of all messy 
aspects of math fonts. (And of course the same is true for automated 
typesetting: it will never be possible to fully automate if only because 
each user has different expectations and conditions are unpredictable).

So, as you mention several links to typographic sites ... it's craft and 
configuring what you want is not too hard. I wouldn't be surprised if 
those who claim that this or that size should be honored on the other 
hand have no problem with messing up the inter character spacing, do 
some optical scaling on the font and worse.

Hans

ps. The same discussion can be held about what features to enable. It 
assumes fonts to be set up properly. I have fonts here that have 
oldstyles shapes as (hard coded) default and regular alternatives so in 
fact they assume onum is explicltly off i guess. While one can argue 
that the font should not have oldstyles as default shapes but in 
alternates. So, opentype can make live easier (no encodings) but also 
demands that users know what and look at what they're doing.

Pointing to what other systems do is pointless as I've heard talks about 
professional typesetting systems that with each version started 
supporting or enabling or showing in menus more 'font features' while in 
fact most otf font features are so generic that you can support them all 
right from the start. So again, in context, you can turn on and off 
features, choose the ones you like, and even add your own. If some 
category is supported, all are. (No additional secret unlock keys needed.)

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________