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?
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).
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.
I tried to find some Chinese/Japanese fonts match your work, but I cannot find one! Are our characters too complex to become geometric?
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...
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.
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.
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.
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.)
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.
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.
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.
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.
Glad you like it, Luke! 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.
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.
Comments
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!
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).
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.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.
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).
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 ى...?
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.
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.
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.
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.
I think the other initial/medial ح was better, the final one is OKish.
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.)
Should final /keheh rather end in a larger bow like /beh?
Thanks for everybody's help!
Yeah, I guess this is better:
Although, perhaps some of the perceived largeness is due to the titling-style architecture? Does it look better with regular-style letters?