Raqeem font system
I want to make an Arabic font file and the main thing should know is that I need to change Arabic font from low logic to high logic as English style. I want to change from the fourth position of the classic Arabic font which is.
These four positions of letters in Arabic classic fonts in words so, we have 4 designs for each letter for all Arabic letters in the classic Arabic font. In Raqeem new system glyphs created by me, there are only two positions upper and lower cases like English that require to delete two positions from the classic one and use the keyboard Caps lock button to switch from upper to lower or vice versa.
There are six letters that require shortcodes keyboard combinations to get it.
I looking for an expert who can build new keyboard layout and font files with four format
You can see my creation glyphs on my twitter post here:
Is layout for your scheme still right-to-left?
1. If you want the text to be automatically laid out right-to-left, then you need to use standard Arabic Unicode character codes for each letter. You can't reliably use Private Use Area codepoints, because those all have default left-to-right directionality.
2. I presume you'd also want to be able to set arbitrary Arabic text strings using the new shapes, so that also implies mapping your shapes to standard Unicode Arabic character codes.
3. Given these encoding implications, the biggest challenge will be your desire to have Arabic behave as a bicameral script with upper- and lowercase. I've thought of a one way to get the casing and keyboarding behaviour you want using standard Arabic codepoints, but it's a really strange hack, and I can imagine that some environments might reject it:
A couple of other possible hacks come to mind, but I couldn't claim any of them to be completely reliable, and what works in one environment might not work elsewhere.
- Encode the uppercase shape glyphs as standard Arabic characters.
- Add to the font a format 14 cmap table that maps sequences of standard Arabic codepoints + a variation selector character to the lowercase shape glyphs.
- [Or vice versa: i.e. you could decide to make the lowercase the default forms and map the uppercase to variation selector sequences.]
- Create a custom keyboard driver that maps unshifted (or shifted, if using for uppercase) keys to the sequence of Arabic codepoint + variation selector.
- There are a couple of likely dangers in this approach:
—Variation selector sequences are supposed to be defined by Unicode, and some environments could apply a validation check and reject your custom sequences;
—Variation selector characters are default ignorable, so some environments could simply not apply the mappings, in which case your display would fall back to whatever shapes are the default.
4. Some layout environments for Arabic text will check a font to see if it has init, medi and fina OpenType Layout features, and may not use the font if these are absent (working from the assumption that Arabic layout requires these features, and hence the font is broken if they are not present). This means that even though you want to display your text using non-joining, static shapes, you may need to build the font as if it contained joining variants. [This is an issue that Saad Abulhab ran into with his own non-joining Arabic fonts.]
Agreed, a character in the PUA has only default Unicode properties, which can have more side effects than LTR.
I also had the idea to insert a non spacing character. A feature rule could use the context for an alternate glyph. But I don't know much about mechanics of Arabic forms, if this can work together.
Seems like existing text would be all one case after just changing the font. One could try to work around this with fancy contextual magic, but that isn't likely to be entirely satisfactory.
If we face that issue with a small caps button what we can do is there possible solutions?
Question: am I right in thinking that you want these fonts primarily for your personal projects and for text that you would be creating? The more direct control you have over how the fonts are used, the fewer compatibility issues you need to worry about. If you were planning to make the fonts available to other people, things get more complicated because then you have to anticipate all the ways in which those people might want to use the fonts.
OK, so you want this to be useable by other people too. To summarize the issues we have mentioned in this thread, there are three questions you need to be able to answer:
You'll need to work out how to fit together these three pieces of the puzzle. For example, I just made a test font with the "small caps" approach. It looked like it was going to work, and testing in hb-view turning on the smcp feature looked good. In TextEdit, it worked wonderfully; but in LibreOffice and Pages, the "small caps" feature was not passed to the shaper for Arabic text. So that's not a viable solution after all.
- How will a user get the text into the computer? Will they type "upper-case Arabic" on a keyboard - and if so, how? If not, how will they signal to the computer that certain glyphs are uppercase? For example: my suggested use of smallcaps would be one way to signal to the computer that glyphs are uppercase, and move the text processing to the font (other kinds of alternates/stylistic sets/etc. would do the same job, but be even harder for the user to access from the interface); another way is that, at least for OS X, the Arabic keyboard does have some glyphs mapped to shift-a (alef-madda), shift-b (peh) etc. But other operating systems map use the Arabic keyboard in other ways, so that's not necessarily helpful.
- Related, what will the document look like on disk - how will the codepoints for uppercase and lowercase Arabic be encoded? Will you use standard Arabic codepoints for "lowercase" or "uppercase" - or for both? Or neither, and use some kind of hack - either private use area or Latin or something else.
- Third, how will you get the shaper to behave? If you use private use or Latin, you won't get the right-to-left shaping behaviour. How will you get the apps to give the right information to the shaper?
From the Unicode FAQ http://www.unicode.org/faq/private_use.html
From the standard https://www.unicode.org/reports/tr9/#Bidirectional_Character_Types
This means that PUA characters CAN have properties, but this must be implemented individually everywhere, in each software component using properties.
Put it this way: would it be odd if all the PUA codepoints had RTL directionality? If so, it's also odd to give them all LTR directionality.
I know only one other standard, HTML, that defines LTR as default for the dir attribute.
Yes, but in practice this means that the default directionality of PUA codepoints is LTR, since this is the default state of almost all text layout environments.
Neither inheriting directionality nor relying on language tagging is very reliable.
Since PUA codepoints only have knowable attributes in an instantiation of a given font, when you can actually see the glyph and, hopefully, know how it should be used, it makes sense that properties for PUA codepoints should be defined at the font level. Apple's TrueType format spec include the Glyph Properties Table, one function of which is to identified mirrored directional pairs (OpenType uses the 'rtlm' OTL feature for the same purpose), and I've pondered whether this idea of defining directionality at the glyph level could be extended to enable assignment of properties to PUA codepoints.
Here is what ICU, used by many applications, does: http://demo.icu-project.org/icu-bin/ubrowse?ch=E001#here. It has only graph=yes, print=yes.
Theoretically BIDI control characters could be used, but many applications ignore them.
A practical solution can only be at the font level.