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 -----------------------------------------------------------------