Freitag — toying around with a geometric display sans
Comments
-
I liked the old ح more, I’d try to add a curved horizontal stroke to it. The ي should be flat by default and only raised after toothed letters, namely initial and medial س and ص, and medial ب (and any other letter sharing the same base).
In your example, you also show an initial ع receiving the raised ي, should that be added to the list? And is CALT the right place to implement it? Is there any special code required to make it work in RTL? I noticed Glyphs starts RLIG with «lookupflag IgnoreMarks RightToLeft;».
As for the /meem, I'm fine with reverting to the circles. The circles themselves fit the geometric theme very well; I was just a bit irked by the departure from the x-height that all other glyphs seem to respect. I guess that's a westernism that I need to let go. ;o)
I suppose I could keep the hill-shaped /meem for SS01 or so...
If I bring back the big arc in /hah and add a rising crossbar, it will rise above the x-height. I guess that's no problem though...?
The problem with the hamzas and the other marks is just that they stack up to vertiginous heights and abysmal depths. I don't feel like stretching the em size of the typeface just to make sure there are no problems with such things. Can I leave line spacing that in the hands of whoever uses the font...? Are such stacking marks used in practice at all?
Thanks for your help!
0 -
-
Christian Thalmann said:
I liked the old ح more, I’d try to add a curved horizontal stroke to it. The ي should be flat by default and only raised after toothed letters, namely initial and medial س and ص, and medial ب (and any other letter sharing the same base).
In your example, you also show an initial ع receiving the raised ي, should that be added to the list?
No, there is a medial ب between the ع and ى that got ligated with the later (basically that raised part of the final ى is part of the other letter).
And is CALT the right place to implement it? Is there any special code required to make it work in RTL? I noticed Glyphs starts RLIG with «lookupflag IgnoreMarks RightToLeft;».
Using calt should be fine, or even liga, the tag does not really matter as long as it is on by default and not for some thing totally unrelated. I’d usually implement this as contextual alternate, but some people go for ligature.If I bring back the big arc in /hah and add a rising crossbar, it will rise above the x-height. I guess that's no problem though...?
Shouldn’t be a problem, Arabic does not even have an x-height, there are like three or for lines to align the shapes at but it varies widely based on design and I simply just design something that looks nice.The problem with the hamzas and the other marks is just that they stack up to vertiginous heights and abysmal depths. I don't feel like stretching the em size of the typeface just to make sure there are no problems with such things. Can I leave line spacing that in the hands of whoever uses the font...? Are such stacking marks used in practice at all?
Arabic usually have grows more vertically than horizontally, tries to squeeze it usually cramps things badly (but that does not prevent many designers from doing). Staked marks in Arabic are rather common in vocalised text, if you feel your design will not be commonly used for vocalised text you can keep tight line spacing for the default and users of vocalised text can use more bigger spacing (but make sure to have big enough Win metrics to avoid clipping in certain brain dead Windows applications).
0 -
I tried to find some Chinese/Japanese fonts match your work, but I cannot find one! Are our characters too complex to become geometric?0
-
No, there is a medial ب between the ع and ى that got ligated with the later (basically that raised part of the final ى is part of the other letter).
Aha, that explains it!
Though I can't imagine how one would render that with a contextual alternate alone, since the ب got completely subsumed. Would it be acceptable to draw the medial ب in full and then add the rising ى...?Arabic usually have grows more vertically than horizontally, tries to squeeze it usually cramps things badly (but that does not prevent many designers from doing). Staked marks in Arabic are rather common in vocalised text, if you feel your design will not be commonly used for vocalised text you can keep tight line spacing for the default and users of vocalised text can use more bigger spacing (but make sure to have big enough Win metrics to avoid clipping in certain brain dead Windows applications).
The problem is that I don't want to increase the typeface's vertical size just to accommodate the Arabic. For instance, I've seen Gentium take up a huge amount of vertical space in Word, and when I tried to reduce the line spacing below 1, it started clipping for no good reason.
For now, my favorite solution would be to keep the Arabic as horizontal as possible and stay within the established vertical bounds. That probably means reducing the ي to a horizontal line... let's see if that works.
I'll also have to avoid the stacking ligatures, then. What's the minimum set of ligatures/contextual alternates that a font must support to be considered functional? Someone on Twitter just said the 213 ligatures in Glyphs were the bare minimum; if so, I can just about forget it.
Of course, I could make a dedicated Arabic spin-off of my font that does have a lot of vertical space. I suppose I should rather save that idea for another time, though... baby steps.
1 -
That could very well be the case; the conceptual space of kanji is so tightly packed that there can't be much wiggle room... I'm not going to attempt a CJK expansion of Quinoa, though. Even with the Arabic I probably bit off more than I can chew...Belleve Invis said:I tried to find some Chinese/Japanese fonts match your work, but I cannot find one! Are our characters too complex to become geometric?
0 -
For now, my favorite solution would be to keep the Arabic as horizontal as possible and stay within the established vertical bounds. That probably means reducing the ي to a horizontal line... let's see if that works.
I'm not sure if it actually does work, but I love the look of this word...
Maybe I would have to give keep the previous design for /alefMaksura.fina so it won't be confused with the outstroke of a final letter.
0 -
That reads السياسب, the dots are a not so important part of ي (in Egypt and non-Arabic languages they are even dropped in final/isolated forms). I think you can go with something like:
. For the ح, I was thinking more along 
.
The font I showed before makes the raised part using contextual substitution, you can check it to get an idea how it is done https://github.com/khaledhosny/amiri-font.
There is no hard rule for what forms you build, it is all up to you, there are legible (though exotic) Arabic font with only one glyph per letter and no contextual forms at all.
0 -
Sorry, I noticed I used the wrong form for the «politician», since it's a toothed letter. I've decided to make the non-dotted versions deeper than the others so that they're more recognizable. How does this work?
This scheme uses an alternate form of both the toothed letter and the final letter; the join is in the bump.
Is this new ح any better?
The /alefMaksura substitution seems pretty important for legibility. Which other substitutions would you consider similarly important? I'm trying to avoid too much stacking, but as long as they're horizontal like the one at hand, I'm willing to give it a try.
0 -
I still think the shallow final ي is not very legible. If you insist, you can go Kufic, which have the advantage that you need only one final form:
I think the other initial/medial ح was better, the final one is OKish.
0 -
The Kufic is pretty, but I guess I'd have to change many other letters too to match it?
You said that final ي is sometimes written without underdots and does not cause problematic confusion with ى, right? In that case, I suppose I could make an exception for that letter and place the dots below the descender line. This way, if they get clipped, it's not so tragic.
As for the initial/medial ح, I understood your earlier post (http://typedrawers.com/discussion/comment/18536/#Comment_18536) to mean that the top-flat form was preferable over the bottom-flat one. Or is the main motivation to keep the design consistent between the positional forms?
BTW, would it be OK to simplify the small /hamza to a /c shape? If not, what if I gave it a corner in the bottom left? That would at least make it easier to fit under the /alef without breaking the descender line... (I suppose it doesn't matter that much if it does, though.)
0 -
Update, including Farsi and Urdu characters:
Should final /keheh rather end in a larger bow like /beh?
0 -
Oh, apparently I completely misunderstood /yehbarree. I thought it was sitting on the baseline! Well, it's a pity for that nice cloud shape, but I fear I have to reduce it to a flat loop.
0 -
-
Just a remark.... Alef is the first letter in Hebrew, Alif is the one in Arabic.
0 -
OK, thanks. I've just been using the character names as they appear in Glyphs for simplicity's sake; it says /alef-ar there.
0 -
-
Alright, the Arabic discussion seems to have died down somewhat. I guess I'll wrap it up here and publish a first «experimental» version of the Arabic. I can always provide an update if I make future changes.
Thanks for everybody's help!
0 -
Just a remark.... Alef is the first letter in Hebrew, Alif is the one in Arabic.
In unicode, and the Adobe glyph list it is called alef.
0 -
Then someone should fix that because In Arabic it is called alif.Georg Seifert said:Just a remark.... Alef is the first letter in Hebrew, Alif is the one in Arabic.
In unicode, and the Adobe glyph list it is called alef.0 -
On a purely personal level I think it's looking fantastic. Those over-extended /f/'s and /j/'s are charming. The numerals feel a little peculiar, especially the rounded connections.1
-
FWIW, this is the note about spelling of Arabic letter names from the Unicode chart itself:
Arabic letter names follow romanization conventions derived
from ISO 8859-6. These differ from the Literary Arabic
pronunciation of the letter names.1 -
Terrific.0
-
Glad you like it, Luke!Luke Prowse said:On a purely personal level I think it's looking fantastic. Those over-extended /f/'s and /j/'s are charming. The numerals feel a little peculiar, especially the rounded connections.
Yes, I do consider the extreme extenders a crucial feature of the typeface; it goes back to the earliest drawings that sent me down this path.
0 -
-
Started with small caps, but I think they ended up too tall. Whaddya think?
Yeah, I guess this is better:
0 -
The smaller ones are definitely better, but I think they could still be a little bit smaller.1
-
I was afraid you'd say that.
I'll start over, then...
Although, perhaps some of the perceived largeness is due to the titling-style architecture? Does it look better with regular-style letters?
0 -
Ahh, yes that does make a difference. But since the titling-style architecture is such a prominent feature, you may want to account for that in the size of your small caps. It's not wrong or ugly as it is, but I still think it could be a bit smaller. If you interpolate from the earlier even larger small caps it shouldn't be too much work.0
-
I see... Do you think I might even get away with x-height small caps for this face? The differences are getting smaller and smaller.0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 799 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports