georgd / EB-Granjon

Experimental repository to EB-Garamond
17 stars 0 forks source link

Italic/Bold Italic Serbian localized glyphs [Cyrillic] #1

Open AleCes opened 13 years ago

AleCes commented 13 years ago

In Serbian ITALIC small letters BE, GE, DE, PE, TE, have mandatory localized glyphs, while SHA is optional. Shapes: BE: already implemented GE: Italic small Latin I + macron DE: Italic small Latin G PE: Italic small Latin U + macron TE: Italic small Latin M REVERSED + overline SHA: Italic small Latin M REVERSED + underline I wished to insert an attachment with images but I can't find the way. Please let me know. Greetings

georgd commented 13 years ago

Thanks for your report! I’m aware of those localized gyphs. In fact, cyrillic glyphs for italic haven’t been drawn yet. What you see in the cyrillic blocks are automatically slanted/composed glyphs. This is on my todo list. You might have overlooked that in this case, д shouldn’t look like the latin italic g but rather like an open g. At least I haven’t seen any serbian text showing the closed form until now. Can you confirm this?

AleCes commented 13 years ago

Hi georgd!

I'm sorry I'm not really into typographical terminology, but if you mean that it should look like a sans-serif g, like the one I see in the box I'm writing in, of course that's what I meant. My reference was LiberationSerif (standard font in LibreOffice on Ubuntu) and in this font the shape of Italic G is different than the regular. This is the shape I think is correct.

While we are at it, I'll drop a few lines about Macedonian glyphs: 1) Upright & Italic small BE, Italic small GE, DE, PE ,TE like their Serbian counterparts 2) No optional Italic shape for small SHA (just normal, Russian SHA) 3) Specifically Macedonian localized glyph for Italic small MACEDONIAN GJE, whose shape is: Italic small Latin I + macron + acute accent, or just small Italic Serbian GE + acute accent.

Again, if only I could insert an attachment with the glyphs, things would get a lot easier.

Last thing: as far as the optional glyph for Serbian Italic small SHA is concerned, it should go in salt & hist lookups.

georgd commented 13 years ago

Thanks for the infos about Macedonian, I’m familiar with the Serbian usage but have no idea of Macedonian usage.

For the lookups, I don’t understand why they should go in hist. In my opinion they should go into locl and perhaps salt (which I’m not using yet, I prefer stylistic sets ssXX and character variants cvXX).

AleCes commented 13 years ago

Hi georgd!

All of Macedonian glyphs and all of Serbian glyphs should go into the locl of the respective language, that's for certain.

BUT in Serbian, ONLY in Serbian there is also an OPTIONAL localized glyph, that should go into the salt & hist SUBSETS of Serbian locl. Why? Because the Russian shape is acceptable too, and therefore the Serbian glyph should be activated only if the typesetter wishes so, therefore > salt, I also suggest hist because this glyph occurred more frequently in the past, while now it is less used.

As far as localized glyphs are concerned, implementing them through salt or stylistic sets, or even character variants is deprecated and I personally don't consider it appropriate: a Russian glyph in a Serbian/Macedonian text is ALWAYS inappropriate, it's not a question of styles of preferences. Vice versa, a Serbian glyph in a Russian text is note a cute feature, but an aberration.

Remember: all of these glyphs: locl but Serbian SHA locl>salt/hist.

I hope I've made my point sufficiently clear.

georgd commented 13 years ago

I think, I got it:

locl SRB,MKD substitute [ be ge gje de pe te ] by [ be.alt ge.alt gje.alt de.alt pe.alt te.alt ] salt subtitute sha by sha.srb

I’m just not so convinced of the salt feature. Enabling this one will enable every replacement set that’s in it, so this might result with replacements one wouldn’t want to have. If this goes into a feature cv85 that only replaces sha by its variant, there won’t be any sideeffect.

AleCes commented 13 years ago

Hi

As far as SHA is concerned, salt/hist ONLY in combination with SRB>locl, otherwise salt/hist alone is bad: if I'm typesetting, say Russian text, a Serbian shape for an Italic SHA is inappropriate, or rather faulty. I think this is what you mean by "this might result with replacements one wouldn't want to have". If not, please let me know.

To sum it up, the SHA shape we're talking about must be available 1) only for Serbian, not Macedonian, nothing else. 2) on demand, that is not automatically selected by locl

If you don't like salt try hist, or other tags, there are plenty of them. To say the truth, I don't know which variants you're referring to: the case of SHA is the only case of stylistic alternative (bound to a specific language) I know of in the Cyrillic alphabet. Last but not least, character variants are friggingly painful to implement, while OpenType tags are far more user-friendly (at least in XeTeX, the engine I use to typeset Serbian). I repeat it, if you don't like salt, at least put it in hist, which is appropriate too, since that glyph was more widespread in the past. You'll save me lots of headaches :) Thanks

So, the implementation I'd love to see would be: Serbian: GSUB>DFLT>cyrl>SRB>locl ON for: BE,GE,DE,PE TE GSUB>DFLT>cyrl>SRB>locl & salt/hist ON for: SHA

Macedonian: GSUB>DFLT>cyrl>MKD>locl ON for: BE,GE,DE,PE TE, MACEDONIAN GJE

Regards

georgd commented 13 years ago

The problem with salt is: there may be a general alternative glyph for a numeral, say one.alt, which would be selected for any language. So a serbian user would never see the normal one when he switches salt on. This can be prevented by having say cv85 managing sha variants (language dependent, if desired) and cv11 manage variants of one. So no conflict can arise. The problem with hist is: if every historical variant gets allocated there, it ends up in an unbearable mishmash with variants covering 16th to 20th century. Therefore, if it’s about a group of (historical) variants, I prefer stylistic sets for them. At least I’ve followed this, until now (you don’t find salt and hist in EB Garamond).

AleCes commented 13 years ago

As far as salt is concerned: OK, but so what's the difference with aalt? As far as "variants covering 16th to 20th" century, I repeat I don't know of any optional variants apart from the Serbian SHA, like I said in the other issue (CYRILLIC FITA), the history of Cyrillic typography is rather different than the Latin, and variants are much more widespread in the uncial Church Slavonic script, while after the 18th century glyph shapes were standardized (and scores of letters were just dropped). To settle things in a dirty way, you could implement the optional glyph for SHA as the standard and then put the version without underline in a cv, but I don't think this is going to satisfy you, does it? It depends on your policy: if you have a policy of privileging "archaic" stuffs, then it could suit the feeling of this font. Anyhow, I'll repeat it for the umpteenth time: adding cv's almost defeats the purpose of adding that glyph in the first place: trust me, they are painfully hard to implement!!! All raw code, and no standard switches.

georgd commented 13 years ago

No, I want the non marked forms as default and “archaic” characters as alternative.

My problem is probably, that my usage of Opentype features is restricted to XeLaTeX/LuaLaTeX, which let me access any feature I want—not hard to implement anything. So I’ve been trying to make a consistent set of features that allows for a fine grained selection of alternate glyphs. What programs do you use?

If you think it is easier to use salt over cvXX I’ll add a salt lookup besides the cv one. It’s not that hard of a work for me, I just didn’t think, this would make so much sense.

Aalt is a different thing. It shall contain all alternatives (that is also sub/superscript, smallcaps, swash, etc.) to be accessible via a glyph palette tool in the users program.

AleCes commented 13 years ago

Quote: my usage of Opentype features is restricted to XeLaTeX/LuaLaTeX So do I, I only use XeLaTeX, I told you that, but as far as my (limited) knowledge goes, fontspec does not allow to switch on character variants, does it? Please if you know how to do it, don't hesitate to tell me, even if we go off topic. There are also stylistical sets but I don't know if that is OK for you.

georgd commented 13 years ago

Sorry, I’ve missed that bit. Fontspec allows to select any feature (even those not officially registered with Microsoft) via RawFeature=abcd so character variants have been available all the time, now they also have human readable name CharacterVariant. You might want to check the current fontspec manual on page 27. And you might also be interested in the EB Garamond specimen and its XeLaTeX source file which relies heavily on OT features. Have a look at it and don’t hesitate to ask me if something’s not clear.

AleCes commented 13 years ago

OK, I've read the fontspec manual pag. 27. Now that I know how it works (sorry for my ignorance, I'm a basic user, I just tend to stick with basic procedures) you can go on with cv's, it sounds good and also it does not imply changes that are not wanted somewhere else, just in the SHA Italic shape. But what about stylistic sets too? You could design an "archaic" set that, coupled with Serbian locl (that's important) triggers also the underlined shape of Italic SHA, among other features. Anyhow, great, if it's so easy, go ahead with character variations, that's OK!

georgd commented 13 years ago

No problem, I often get the impression that opentype features smell of secret wisdom :) But to be honest, I’m still waiting for protests from Adobe products users. Anyhow, I’ll go ahead this direction for now.

AleCes commented 13 years ago

Open-Type features "smell of secret wisdom" because there is no mainstream software support for them, apart from Firefox 4, but anyway you're not going to typeset text in Firefox, I mean Office 2010 at last implemented some, actually very few features, just basic ligatures and kerning (at least it stops displaying those crappy collision between f and i). But still, as far as I know, no localization, no stylistic sets, let alone character variations. And Adobe fonts suck, they cost loads of $, have minimal OpenType features, buggy kerning, and work well only on Adobe InDesign (which cost even more $) that very likely triggers some undocumented non-OpenType features in order to override the defective Open-Type implementation. Adobe fonts user should dump that crap and make the transition to opensource fonts, just as I did.