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
___________________________________________________________________________________
