Underlining in non-Latin scripts

SIL Fonts
1

Are there functional equivalents to underlining in non-Latin scripts?

If so, what are they, and to what extent do SIL fonts support them?

1 Like
2

I wrote a paper many moons ago: Challenges in publishing with non-Roman scripts. There’s a pdf on Academia if you would prefer. Look at section 1.4.1

We also know the Chinese (and Miao and possibly Tibetan…) system is kind of like this:

  • names of people – single underline
  • names of places – double underline
  • book titles – wavy underline

I don’t think the wavy line is a font setting. I kind of think the double and wavy lines should be settings in an app.

1 Like
3

I think you’re asking whether there are non-Latin visual equivalents of the semantic properties that we often use underlining to indicate in Latin. Typically that would be emphasis, and possibly some typographic hierarchy. How scripts indicate these differ from script to script - bolding, other styles, size change. Because of international usage, some people in other scripts have informally and inconsistently adopted underlining for things, 'cause there’s that useful U button in Word. There’s nothing about our non-Latin fonts that stops anyone from using the variety of higher-level style adjustments (underlining, strikethrough, etc.) an app provides, including underlining.

Web usage of underlining (solid or dotted) is a bit unique in that it’s often used for links, and that will still work no matter what script is active.

4

Following up on this after discussions elsewhere:

It seems that you are needing to find visual ways to distinguish text for annotation purposes, and that you need a wide variety of ways to do that which are typographically appropriate for the script. Examples: underlining, double underlining,. brackets, boxes, highlighting, bold, outline, and everything in various colours.

You can approach this in two ways:

  1. Take your list of annotation types and try to find what is the most natural and typographically appropriate representation for that semantic annotation type for each script you support. This is ideal, but would require a huge amount of research and testing with local script experts. This might work well in a single-script environment, where all editing and authoring uses the same script. However, if the user encounters more than one script, even in separate panes/windows, having the same semantic annotation represented in two different ways will be confusing. And what if you use the same visual marking to mean two different things in different scripts?

  2. Use a consistent set of visual annotation marking methods across all scripts. You won’t get the benefit of leveraging existing typographic patterns but you’ll have UI consistency. You may want to think through whether there are certain troublesome script+annotation combinations you may want to avoid, or use color to increase differentiation, or at least apply them to rarer annotations. Examples of this would be: line above text for Devanagari (which already has a line at the top), and dotted underline for fully-marked Hebrew (which has marks underneath).

I’d recommend you follow the second strategy, although that doesn’t guarantee all will be well, even with Latin. Both Vietnamese and Yoruba use dots underneath as part of their writing system, so a dotted black underline might not work well there either. Any annotations for a complex script like Nastaliq could be difficult, and there’s no easy technical way around that.

We can help you identify where you may encounter problems. The best way to do that would be for you to come up with a draft set of annotation markings, in order by commonness, and noting which if any will use color. Then we can review that and point out if there are any that may be troublesome for the more common scripts.

As for font support: You probably can’t expect specific fonts (including SIL ones) to have built-in support for any of your annotation marking methods except for the common ones (bold, underline, strikethrough). Keep in mind that you cannot easily apply color to in-font features unless you use one of the color font formats. We’re not contemplating producing COLRv1 or OpenType-SVG versions of our fonts, so that’s not a reasonable option for you. Even if we did, you’d then be limited to using only those SIL fonts.