HN Debrief

Digital Printing of Arabic: explaining the problem (2017)

  • Typography
  • Internationalization
  • Web
  • Developer Tools
  • Education

The article argues that Arabic script never fit neatly into the assumptions of print and computing, and that digital systems still flatten or mishandle parts of the writing system that matter to readers. People reading it in 2026 mostly agreed with the premise, but sharpened where the pain now sits. Basic glyph shaping is no longer the main blocker. HarfBuzz, OpenType, Graphite, and specialized fonts can render a lot of Arabic-script text correctly. The persistent failures are higher up the stack: operating systems that make it hard to pick the right font, browsers and apps that still lack typography features like kashida, search and copy-paste that break on normalization and right-to-left edge cases, and text editors whose cursor behavior becomes confusing the moment bidirectional text appears.

If your product handles user text, do not assume Unicode plus a modern font stack means Arabic support is done. Audit editing, search, font choice, and right-to-left behavior with native readers, because the remaining failures are often in defaults and UX, not in the shaping engine.

Discussion mood

Mostly sympathetic and frustrated. People accepted that Arabic-script support is still worse than it should be, but many pushed back on framing this as a deep unsolved rendering problem. The mood was that the hard parts are now mostly product neglect, weak defaults, and incomplete handling of right-to-left text across the stack.

Key insights

  1. 01

    Cursor movement is still broken muscle memory

    Editing bidirectional text remains miserable even when the glyphs render fine. Arrow keys usually map to logical start and end rather than visual left and right, so the cursor appears to jump backward inside a short right-to-left run embedded in English text. That makes everyday selection and navigation feel buggy even when the implementation is technically correct.

    Test text editing with mixed English and Arabic or Persian content, not just static rendering. If your app has custom editors, you may need visual cues or different navigation behavior to keep users oriented.

      Attribution:
    • linmer #1
  2. 02

    Nastaliq is available but not surfaced

    The interesting constraint is no longer 'can computers shape Nastaliq' but 'will mainstream products expose it'. Nastaliq needs richer contextual shaping than Naskh, which makes font design harder, but commenters pointed out that fonts like Awami Nastaliq and Noto Nastaliq Urdu already exist and modern engines like HarfBuzz can handle them. What users still hit is platform policy. Android and other systems often lock them into the wrong default script style unless they root devices or swap system fonts.

    If you ship to Urdu or related markets, treat script style as a product requirement, not a localization footnote. Verify your default font stack with native readers and expose font control where the system will not.

      Attribution:
    • bradrn #1
    • linmer #1
    • ablob #1
    • yorwba #1
    • abdullahkhalids #1
  3. 03

    Unicode solves less than application developers think

    Several comments recast the article's examples as stack-integration failures rather than flaws in Unicode itself. Normalization, locale-aware search, bidi handling, and language-specific font selection are all separate jobs. If any one of them is skipped, copy-paste, search, and display degrade fast. The practical point is that 'supports Unicode' is close to meaningless as a product claim for Arabic-script languages.

    Review your search indexing, normalization pipeline, and language tagging separately from rendering. A passing Unicode smoke test will miss the bugs users actually feel.

      Attribution:
    • numpad0 #1
    • Karliss #1
  4. 04

    This affects far more than Arabic

    The impact extends across a large family of languages that rely on Arabic-derived scripts, often with weak institutional support in software. Commenters tied that to history as much as engineering. In many places, economic and political power sits with English or French, so local-language computing never got the same sustained investment. That leaves users depending on software built elsewhere, where their script needs stay invisible.

    Do not size this problem by counting Arabic speakers alone. If your product targets South Asia, the Middle East, or diaspora users, budget for script support as part of market access.

      Attribution:
    • abdullahkhalids #1 #2
  5. 05

    Web typography still misses kashida

    Arabic support on the web still lacks native handling for kashida, the elongation used for justification and emphasis. The complaint was not about decorative calligraphy. It was about a normal typographic tool that CSS still does not expose in a useful way. That means web text often falls back to spacing strategies that look wrong to readers even when every character is technically present.

    If web presentation quality matters in Arabic, assume browser defaults are not enough. Plan for script-specific typography review and track standards work instead of treating parity with Latin layout as finished.

      Attribution:
    • mohsen1 #1 #2

Against the grain

  1. 01

    The article overstates what remains unsolved

    A detailed pushback argued that many examples in the essay were already old failures by 2017 and are even less persuasive now. Modern digital text can overlap glyphs, do contextual substitutions, and normalize composed characters. The more useful question is which applications still fail to apply known techniques, not whether computers are fundamentally unable to handle Arabic script.

    Use the article as a map of failure modes, not as a current technical baseline. Before committing engineering effort, identify which bugs are still present in your target platforms and which are already solved by existing libraries.

      Attribution:
    • Karliss #1
  2. 02

    Arabizi will not fix literacy

    The claim that romanizing Arabic would raise literacy got a direct rebuttal with a simple comparison. Many Arabic-speaking countries already have high literacy, while Somali uses the Latin alphabet and still has low literacy. Access to education dominates script choice here. Romanization may ease typing in some contexts, but it does not address the real bottleneck.

    Do not confuse script conversion with user enablement. If your goal is adoption or literacy, invest in education, input tools, and native-script support before betting on transliteration schemes.

      Attribution:
    • yorwba #1
  3. 03

    Han unification is not Arabic's model answer

    A side debate challenged the article's favorable mention of CJK unification. Some argued it remains politically charged and can pick the wrong glyph forms for a language, while others said those differences mostly belong in font selection. Either way, commenters agreed it is not a clean precedent for Arabic. Unifying code points does not remove the need for language-aware rendering and good defaults.

    Be careful borrowing cross-script lessons from Unicode history. What worked or failed for CJK does not automatically transfer to Arabic, especially when font selection and language metadata are doing most of the real work.

      Attribution:
    • yorwba #1
    • numpad0 #1
    • ablob #1

In plain english

Android ↩
Google's mobile operating system used on many smartphones and tablets.
Arabizi ↩
An informal way of writing Arabic with Latin letters and numerals, often used on older devices or in casual messaging.
Awami Nastaliq ↩
A font from SIL built to support Nastaliq rendering for Urdu and related languages.
bidi ↩
Bidirectional text handling, the rules software uses when right-to-left and left-to-right text appear together.
CJK ↩
Chinese, Japanese, and Korean, often grouped together in computing because of shared character encoding issues.
CSS ↩
Cascading Style Sheets, the language used to control how web pages are styled and laid out.
Graphite ↩
A smart font system from SIL that allows fonts to include advanced shaping behavior beyond what some other font systems support.
HarfBuzz ↩
An open source text shaping engine that turns Unicode text plus font rules into the correct positioned glyphs for complex scripts.
kashida ↩
A typographic elongation used in Arabic script to justify text or add emphasis by stretching connections within a word.
Naskh ↩
A more standard Arabic script style commonly used in print and digital text, with simpler baseline-aligned shaping than Nastaliq.
Nastaliq ↩
A calligraphic style used especially for Urdu and Persian that has complex diagonal joins and variable vertical positioning.
Noto Nastaliq Urdu ↩
A Google font designed to render Urdu in the Nastaliq style.
OpenType ↩
A font format that supports advanced typographic features such as ligatures, contextual substitutions, and script-specific shaping rules.
Unicode ↩
The standard system for assigning numbers to characters from many writing systems so computers can store and exchange text.

Reference links

Fonts and script rendering

  • Awami Nastaliq special features
    Used to illustrate why Nastaliq requires richer shaping behavior and how a production font handles it.
  • Graphite font demo
    Shows Graphite-based rendering for advanced fonts, mentioned in connection with Nastaliq support in Firefox.
  • Noto Nastaliq Urdu specimen
    Example of an available modern Nastaliq font that commenters said should be easier to use on mainstream systems.
  • HarfBuzz WebAssembly examples
    Referenced as evidence that complex shaping problems still surface in web deployment and font handling.

Technical background

Script and language references

  • Nastaliq on Wikipedia
    Background reference for the script style Urdu traditionally uses.
  • Naskh script on Wikipedia
    Background reference for the more common digital default style contrasted with Nastaliq.
  • Kurrent on Wikipedia
    Used in an analogy about older scripts becoming unreadable when education and tooling move on.
  • Sütterlin on Wikipedia
    Mentioned in a comparison about whether script-specific visual variants should be encoded or left to fonts.

Literacy and policy context