Who is most familiar with OpenType features?

[Ahzoh]

I’ve been trying to make a font that can allow my conscript to be used both horizontally RTL and vertically LTR and also be cursive like Arabic.

I was successful in making it cursive and RTL, using the contextual alternates feature in OpenType and assigning the codepoints to a RTL language’s codepoints, namely the Adlam script.

To achieve vertical writing, I have used HTML code for a workaround, though the exact code is not as simple as “writing-direction: vertical-lr” which rotates the text 90 degrees clockwise and only works for scripts like Mongolian whose horizontal letters are actually upside down. My letters are right side up so it isn’t going to rotate them properly. But I digress.

But I’m not really fond of these solutions, especially since I want to eventually have it under the Conscript Registry thing’s set of codepoints and that’s all private use area, which is, according to Unicode’s code, is basically “inherently LTR”, so I won’t get the RTL functionality unless I want to mess around with how Unicode assigns text directionality to their codepoints.

However, I’ve noticed that OpenType has these features like Right-to-Left Alternates (rtla) and Vertical Alternates (vert). Problem is, I don’t really understand how to use them and how I’m supposed to turn on those features when actually typing. I’ve looked at actual Mongolian script font and how they use the vert feature, but I don’t know how they manage to turn on that feature. All it shows in the code is to substitute certain glyphs with a rotated variant.

I dunno, anyone here worked extensively with OpenType features (either specifically these issues or in general) in their fontmaking?

[Kuchigakatai]

I have never done any font work, but I remember our old member guitarplayer struggling with similar uses and saying that, unfortunately, font rendering leans heavily towards natlang usage, as appropriate for the ranges as defined for natlangs, instead of arbitrary properties that may be used in conscripts. So creative usage like yours might involve fiddling with font rendering too. That said, I have seen Arabic fonts with glyphs in the Private Use Area (for fancy alternative shapes of letters), so it is possible to have RTL glyphs there. Also, guitarplayer liked to use the even less widespread Graphite technology (by SIL, supported only in some applications), because it easened diacritic placement (or something), which surely increased his woes. Again, please note I don't really know what I'm talking about.

[Ahzoh]

That said, I have seen Arabic fonts with glyphs in the Private Use Area (for fancy alternative shapes of letters), so it is possible to have RTL glyphs there.

Interestingly enough, despite the fact that individual forms (isolate, initial, ligatures, etc.) of Arabic and similar cursive sripts (like Mongolian) are assigned to their own unicode codepoints, in the actual fonts in the OpenType code, the necessary substitutions involve glyphs that aren't assigned to any codepoints at all (e.g. Arabic Letter Beh.init isn't assigned to any codepoints). So I don't really know what's going on with those codepoint-assigned forms.

[Richard W]

The enabling of OpenType features is external to the font. You're likely to get better control in LibreOffice and Firefox.

You might be better off using the PUA and embedding the text in RLO...PDF. Do you really need the Bidi algorithm? You may need to stick to HarfBuzz clients for rendering. They include modern MS Edge! I think HarfBuzz allows some shaping by default even for the PUA. Browsers allow web pages to enable arbitrary features. As far as I am aware, Word allows only a predefined pick list.

The OpenType spec barely hints at the data held about individual glyphs. This data is derived from the corresponding codepoints and their neighbours in the character stream. So for Arabic, it looks at the neighbours of the codepoints and knows whether a Beh will be initial, medial, final or isolated. There will be features in the font turning letters into the various forms, but the rendering engine decides which feature is applied to which glyph. The fact that Unicode has separate characters for the individual position is now just an embarrassment. New Arabic script letters don't get positional forms - that is handled at the font level. What they do get from the standard is joining type and the like, so that shaping engines can work out what features to apply.

[Ahzoh]

The enabling of OpenType features is external to the font. You're likely to get better control in LibreOffice and Firefox.

Well what I mean is, if I give my font the feature of "vertical alternates" and then under that section list the necessary substitutions of glyphs, when I upload my font to ConWorkshop, using the <span style="writing-direction: vertical-lr"> command doesn't do anything to turn on the vertical alternates feature and thus doesn't substitute my horizontal glyphs for vertical ones (although it does still rotate my letters, just not in the right direction) and using the <dir="rtl"> doesn't seem to enable right-to-left alternates either.

You might be better off using the PUA and embedding the text in RLO...PDF.

I tried to use the RTL marker letters but they don't do anything.

Do you really need the Bidi algorithm? You may need to stick to HarfBuzz clients for rendering.

I don't know what all these are. Although I did read a discussion on another forum about editing shaper.txt to change the writing direction of unicode codepoints (though I can't find shaper.txt).

This data is derived from the corresponding codepoints and their neighbours in the character stream. So for Arabic, it looks at the neighbours of the codepoints and knows whether a Beh will be initial, medial, final or isolated.

Yea, they all use the init, medi, and fina features, which I've tried to do when I assigned the codepoints to Arabic but they don't work anyways, even though those features don't use any codepointed alternate forms. Instead I've had to use normal contextual alternates and then chained substitutions.

[Richard W]

To achieve vertical writing, I have used HTML code for a workaround, though the exact code is not as simple as “writing-direction: vertical-lr” which rotates the text 90 degrees clockwise and only works for scripts like Mongolian whose horizontal letters are actually upside down. My letters are right side up so it isn’t going to rotate them properly. But I digress.

This problem with Mongolian is that horizontally it's left-to-right, whereas it was originally (possibly before the Mongols ever used it) right-to-left.

If Unicode hadn't been riddled with sinophile chiralists, would you have a solution of sorts if one could display multi-line Arabic text rotated by 90 degrees so that it started in the top left, being top-to-bottom within columns, and with the columns ordered left-to-right? So do you actually need some tweaking if it is written vertically?

[Ahzoh]

This problem with Mongolian is that horizontally it's left-to-right, whereas it was originally (possibly before the Mongols ever used it) right-to-left.

No, I mean the Mongolian letters are actually upside down relative to normal letters and its ancestor scripts

Mongolian at left, both horizontal orientation and with proper vertical orientation; My conscript at right, both horizontal orientation and with proper vertical orientation. As you can see, because my conscript letters aren't upside down, the means I must use to achieve a similar effect is far less parsimonious than I'd like:

[Richard W]

I'll take your points out of order, as I think my replies then make more sense.

This data is derived from the corresponding codepoints and their neighbours in the character stream. So for Arabic, it looks at the neighbours of the codepoints and knows whether a Beh will be initial, medial, final or isolated.

Yea, they all use the init, medi, and fina features, which I've tried to do when I assigned the codepoints to Arabic but they don't work anyways, even though those features don't use any codepointed alternate forms. Instead I've had to use normal contextual alternates and then chained substitutions.

This is worrying. Such features have to work in the other scripts, such as Syriac and Mongolian, as the renderer can't be doing anything else. Where did this failure occur? How are you checking that your font is what you expect it to be? How close to the metal can you work? I wrote my own font analyser and compiler. (For licensing reasons, I published them at http://wrdingham.co.uk/fonts/oft.html. Sharp edges remain.) I find AFDKO extremely confusing. However, the triggering of these three features is likely to vary from script to script, as one wants different rules for English, so you're probably better off doing it yourself. I have similar feelings with Indic rearrangement - fascistic dotted circles are a high price for centralised code.

Do you really need the Bidi algorithm? You may need to stick to HarfBuzz clients for rendering.

I don't know what all these are. Although I did read a discussion on another forum about editing shaper.txt to change the writing direction of unicode codepoints (though I can't find shaper.txt).

HarfBuzz is the open source OpenType shaper used for Linux, Android and Chrome. It is used instead of the native renderer by Firefox, Chrome, LibreOffice and, incredibly enough, MS Edge. It includes a gash renderer hb-view that can be used for testing fonts, granting the user command-line control of the features and script and directionality assumed. It needs a C++ compiler, but only uses the C library to run. It also contains hooks for SIL Graphite, and of late an Apple Advanced Typography (AAT) capability has been under development, which may provide an escape for those of us tired of fighting the lack of an OpenType behavioural specification.

The Bidirectional (Bidi) Algorithm essentially takes a sequence of words and puts them in a sequence of left to right and right to left runs of characters. It allows for bracketing, both visually and by means of bidi control characters, so it can handle things like an English sentence quoting a Hebrew sentence quoting an English sentence. Some of these brackets can force everything included in them to be treated as left-to-right (or right-to-left) characters. Thus, to quote some Egyptian hieroglyphs in the normal ancient Egyptian writing order, you can bracket the hieroglyphs in RLO...PDF. (The modern writing order is left-to-right, seemingly even in Arabic publications!) ‮This is an example of RLO...PDF at work.⁩

You might be better off using the PUA and embedding the text in RLO...PDF.

I tried to use the RTL marker letters but they don't do anything.

Do you mean LEFT-TO-RIGHT MARK, RIGHT-TO-LEFT MARK and ARABIC LETTER MARK? They're just zero width letters one can add so that the Bidi algorithm gets the right results. For example, symbols at the start or end of text may need to be protected by such marks in case the text is embedded in a context with a different directionality.

The enabling of OpenType features is external to the font. You're likely to get better control in LibreOffice and Firefox.

Well what I mean is, if I give my font the feature of "vertical alternates" and then under that section list the necessary substitutions of glyphs, when I upload my font to ConWorkshop, using the <span style="writing-direction: vertical-lr"> command doesn't do anything to turn on the vertical alternates feature and thus doesn't substitute my horizontal glyphs for vertical ones (although it does still rotate my letters, just not in the right direction) and using the <dir="rtl"> doesn't seem to enable right-to-left alternates either.

In a decent browser, you can force features on or off. For example, in a CSS style of an HTML section one could have

.hack {font-family: dl1; font-feature-settings: "ss02" 1}

to use font dl1 (a web font in this case) with feature ss02 forcibly enabled. One can do similar things with fonts in several word processors, e.g. LibreOffice. One could thus force the use of the vert feature. I don't know why the rtla feature isn't working. Does it work when you write your own HTML and view it?

[Richard W]

This problem with Mongolian is that horizontally it's left-to-right, whereas it was originally (possibly before the Mongols ever used it) right-to-left.

No, I mean the Mongolian letters are actually upside down relative to normal letters and its ancestor scripts

Yes. That 's what happens when you change from right-to-left to left-to-right by rotating the page rather than by mirroring.

Are horizontal lines of Mongolian text ordered from bottom to top? I had the impression that they didn't do that.

What hoops do you have to jump through to write vertical Arabic so that the text just looks rotated by 90 degrees?

[Ahzoh]

What hoops do you have to jump through to write vertical Arabic so that the text just looks rotated by 90 degrees?

I have to use either <span style="writing-mode: vertical-rl; transform: scale(-1, -1)" dir="rtl"> or <span style="writing-mode: vertical-rl; text-orientation: sideways-right; text-align: right; transform: rotate(180deg)">, both seem to produce the same result.

It's clunky and gross and annoying to type within each table cell. I could use css of course and assign a name to the table cells but the syntax is very messy and confusing. Shit begins and ends with .randomletters

Does it work when you write your own HTML and view it?

I use Conworkshop to test HTML, not sure it can use CSS though.

[Richard W]

What hoops do you have to jump through to write vertical Arabic so that the text just looks rotated by 90 degrees?

I have to use either <span style="writing-mode: vertical-rl; transform: scale(-1, -1)" dir="rtl"> or <span style="writing-mode: vertical-rl; text-orientation: sideways-right; text-align: right; transform: rotate(180deg)">, both seem to produce the same result.

You shouldn't expect it to be easier than with Arabic.

It's clunky and gross and annoying to type within each table cell. I could use css of course and assign a name to the table cells but the syntax is very messy and confusing. Shit begins and ends with .randomletters

I think an HTML element can belong to multiple classes. I'm not sure how inheritance works - it's probably based on a measurement of specificity which only a computer can understand.

Does it work when you write your own HTML and view it?

I use Conworkshop to test HTML, not sure it can use CSS though.

Why don't you use your browser? Without CSS, you haven't got a modern browser.

[Ahzoh]

Well, since I assigned my letters to a RTL script's codepoints the <span style="writing-mode: sideways-lr; text-align: right"> produces the desired result and is far more parsimonious (doesn't work with PUA characters though, and tragically sideways-lr and rl don't work on most browsers). Also it does look like CWS uses CSS.

Why don't you use your browser? Without CSS, you haven't got a modern browser.

What? CWS is a website, I have to use a browser to get there and I use Firefox, which I know uses CSS. But an individual website may have unupdated HTML.

[Richard W]

That's curious.

Code: Select all

<html>
  <head>
    <title>RTL Latin</title>
  </head><body>
    <p style="writing-mode: sideways-lr; text-align: right">
&#x202e;This is an example of RLO...PDF at work.  So how does very long text work?  Does it just get silly?
    </p>
  </body>
</html>

works very nicely for me. Am I just seeing ASCII privilege at work? The text displays in right-to-left order, with the bottom of each line on the right, top-aligned, and columns progressing from left to right. The browser is Firefox and the distribution is Ubuntu 20.04.

The magic is that RLO character, U+202E.

[Ahzoh]

Sadly sideways doesn't work on most browsers that aren't Firefox, so I'd have to use the other code.

Might still have to employ vertical alternates in OpenType if I want to display it correctly on MediaWiki such as FrathWiki

[Richard W]

Sadly sideways doesn't work on most browsers that aren't Firefox, so I'd have to use the other code.

My point is that RLO should convert PUA codepoints to right-to-left codepoints (bc=R). Also, you can use it as a character entity, so it's not an invisible boobytrap. I left U+202C POP DIRECTIONAL FORMATTING out; it's implicit at 'end of paragraph'. The downside is that you can't have any left-to-right stretches within the switched text; that may well not be a problem for a conscript.

[Ahzoh]

Sadly sideways doesn't work on most browsers that aren't Firefox, so I'd have to use the other code.

My point is that RLO should convert PUA codepoints to right-to-left codepoints (bc=R). Also, you can use it as a character entity, so it's not an invisible boobytrap. I left U+202C POP DIRECTIONAL FORMATTING out; it's implicit at 'end of paragraph'. The downside is that you can't have any left-to-right stretches within the switched text; that may well not be a problem for a conscript.

It's a good workaround if I don't want to/can't use HTML, but I would have to do it for every paragraph I type, which can be a hassle to keep track of in Latin script since it's invisible. I don't know what's meant by "character entity" and how it wouldn't make it an invisible boobytrap. You mean assign a glyph to it?

[Kuchigakatai]

My point is that RLO should convert PUA codepoints to right-to-left codepoints (bc=R). Also, you can use it as a character entity, so it's not an invisible boobytrap. I left U+202C POP DIRECTIONAL FORMATTING out; it's implicit at 'end of paragraph'. The downside is that you can't have any left-to-right stretches within the switched text; that may well not be a problem for a conscript.

It's a good workaround if I don't want to/can't use HTML, but I would have to do it for every paragraph I type, which can be a hassle to keep track of in Latin script since it's invisible. I don't know what's meant by "character entity" and how it wouldn't make it an invisible boobytrap. You mean assign a glyph to it?

"&#x202e;" (the HTML character entity for Right-to-Left Override = RLO) is pretty visible wihin HTML source. If you're writing HTML, you don't have to use the actual invisible Unicode character when you can use the readable identity looking like &#x[hexadecimal number].

[Richard W]

Sadly sideways doesn't work on most browsers that aren't Firefox, so I'd have to use the other code.

Might still have to employ vertical alternates in OpenType if I want to display it correctly on MediaWiki such as FrathWiki

On Frathwiki, you're recommended to wrap your text in a template invocation. You can also set up a style element to define your font - there is a template for that. You could use the style element to define two fonts, one for horizontal text, and the other for vertical text, which differ by what features are enabled - the browser should only download the font once. Wiktionary and Wikipedia use such wrapping to render Mongolian from fonts. Just impose a rule that only right-to-left text may appear in your templates. It could be a bit awkward if your script has decimal numbers with the most significant digit on the left (N'ko doesn't - it's on the right), but as you're in the PUA you don't have to follow the rule that decimal place notation is bigendian. If you follow the restriction that the text in the invocation fits within a paragraph, then your bespoke templates can wrap the text in RLO and PDF.

I'm assuming members are allowed to write their own templates. Perhaps someone can advise if one can't.

[Ahzoh]

On Frathwiki, you're recommended to wrap your text in a template invocation. You can also set up a style element to define your font - there is a template for that. You could use the style element to define two fonts, one for horizontal text, and the other for vertical text, which differ by what features are enabled - the browser should only download the font once. Wiktionary and Wikipedia use such wrapping to render Mongolian from fonts. Just impose a rule that only right-to-left text may appear in your templates. It could be a bit awkward if your script has decimal numbers with the most significant digit on the left (N'ko doesn't - it's on the right), but as you're in the PUA you don't have to follow the rule that decimal place notation is bigendian. If you follow the restriction that the text in the invocation fits within a paragraph, then your bespoke templates can wrap the text in RLO and PDF.

I'm assuming members are allowed to write their own templates. Perhaps someone can advise if one can't.

Those templates didn't work at all. Though it looks like the common.css page of the wiki would have to be edited, but only the admin can edit it, so my struggle is fruitless.

[Richard W]

Those templates didn't work at all. Though it looks like the common.css page of the wiki would have to be edited, but only the admin can edit it, so my struggle is fruitless.

Did you investigate where they failed? I can see a number of possibilities:

• The style element is rejected because it is in the body of the HTML. (I'm not at all sure what the rules of HTML5 are - they seem quite permissive compared wit the HTML4 syntax.) It may also be that they only work at the start of the page - I can imagine Media Wiki restructuring the pages it serves to put such elements in the head.
• Your font wasn't served to your browser from the website. If you'd uploaded it to Frathwiki, it should have worked - unless an upload only takes effect after administrative review. A laxly built renderer can easily have problems with memory access violations induced by a malicious fault, so there may be some checking of fonts going on. If you're using the font from another website (e.g. your own), you may have to enable 'Cross-Origin Resource Sharing' (CORS), which can require fiddling with .htaccess files. I've pondered doing it with my fonts, but I'm a little worried that serving the world might not constitute 'fair use'. (The world population of users of my fonts reaches at least three binary digits.)

If you tell us the Frathwiki page name, someone, ideally a member, may investigate the matter for you. Which browsers did you try? Firefox has horribly strict CORS rules. It's a long time since I last checked HTTP headers and I grope my way around the inspection system in browsers.

Does editing your own CSS file on Frathwiki (possibly User:Ahzoh/common.css) solve the problem to the extent that you can see your page as it should be? I have a simple working one on Wiktionary of the form

Code: Select all

.classname {...}