Serious Typos (Progressive CSS)
Robust Vertical Text Layout"Legiblity … a word that can lead into an ocean of misunderstanding and argument"
. Hague, 1936 (via Dear Reader)
With this posting I am starting a series of articles that explore the meaning and myths of legibility and readability. In this first article I am gonna start with the definition of terms and the presentation of model to incorporate these terms in a consistent system, that reflects common problems when setting type.
Definitions of Legibility & Readability
Legibility and readability are common terms within different areas. Surprisingly, convincing definitions are hard to find and in different areas very different things are meant. In psychology scientist who study reading usually just talk about the time we need to read a certain text. In linguistics it is all about the content and the structure of the information. And in typography we usually mainly care about the visual presentation of the text.
In typography we often judge typefaces to be more or less legible than other typefaces. Certain typefaces from the era of Renaissance and Baroque (Garamond, Jenson, Bembo, …) are said to be some of the most legible typefaces. But if that is true, why is it, that road signs are never ever set in one of these typefaces? Isn't legibility a key issue for road signs? Shouldn't we then use the most legible typeface for road signs?
This problem puzzled me ever since I started to think about the legibility of signs or type in general. In order to solve it, at first, a clear definition of all relevant terms is indispensable. In the most broad sense, legibility deals with the perception or decoding of information and readability deals with the understanding of these information. Imagine taking a mountain hike. You can clearly perceive your surrounding. You recognize the mountain range at the horizon, you remember the path you walked and everything salient along it. You can perceive your surrounding and understand it. But suddenly mist comes up. Your surrounding instantly becomes illegible. You can't make out the paths, trees and mountains that surround you. Even if you would proceed, without a clear perception of your environment, you would eventually loose your understanding of where you are and where you are headed. So a clear decoding of the information in your environment is essential for understanding it. But understanding is not always the logical outcome of decoding information. The mist might clear up and you have no trouble perceiving your surrounding again. But you went too far and now everything looks unfamiliar and you have lost your understanding of where you are what you see. Still, in that same environment, an experienced guide is literally able to read the information in the environment, which means he can not only perceive them, but understand them and easily find the way back to the starting point of the trip. So in a literal sense, to read means to interpret or to understand certain information. Legible on the other hand comes from the Latin legere, meaning just to gather, collect or to pick out.
This example of decoding and understanding information is also true for reading text. To decode letters and words, they need to be legible-thus perceivable. They need to stand out from the background, they need to have a proper size and letter spacing to be decodable and so on. So legibility describes the ease or speed with which letters or other pieces of information are decoded. Readability is the aim. At best, the reader should not only perceive the information, he or she should also understand it. This is based on a legible typesetting and the content and writing style of the author. But understanding is also a rather subjective issue. People with proper eye sight will all perceive the silhouette of a mountain range in more or less the same way. But to make use of it, we also need to understand its meaning within a bigger context. And letters are not different in this regard. A big chinese letter might be perfectly legible by itself, but I will not be able read it. It is a visual piece of information I can easily perceive, but not understand. In the same way, a specialized scientific text might make perfect sense to one individual, but might be incomprehensible to another. So, in a textual or typographic sense, legibility deals with the perception or decoding of letters and words and readability deals with their understanding.
With this clear distinction between legibility and readability it is much easier to talk about all kinds of phenomena of reading. But to fully understand what makes certain texts and typefaces more legible that others, we need an extended model, which I will present here. I dubbed it …
The Onion Layer Model of Legibility
Before I even started thinking about the design of new wayfinding typeface, I needed a clear theoretic framework to talk about all aspects of legibility. The literature in graphic design and typography frequently mentions the importance of legibility, but definitions and the explanation of relevant factors are rather seldom and sometimes even contradictorily. So in the end, I had no choice but to build my own model. And I will present the basics of it in this article.
One of the most important factors of legibility, which is sadly often neglected is simply the context. Is is rather pointless to talk about legibility without specifying what is supposed to be read, by whom and under which circumstances. Reading one word on a direction sign while driving is very different from reading a 300-page novel in an armchair. These different uses have very different requirements concerning the typeface and the typesetting. So in my model the context is the basis of the model itself.
Now we get to the typesetting itself. It is grounded on basic principles of perception and Gestalt laws. In our model this is represented by the outer layer of our onion. We need to lay out the information in a way in which they can be perceived and decoded. This is influenced by parameters of the used materials, the surrounding (e.g. lighting) and many typographic factors (like letter spacing, line height-just to name a few). Like I said before, these parameters are basically objective. They can easily be measured. For example, we can define type sizes, minimum viewing distances, background/foreground contrasts and so on, which are necessary to pick up the information for people with a certain level of eye-sight. In Germany some colleagues and I are currently updating the norm "DIN 1450 legibility" which does exactly that.
The inner (blue) layers of the model describe the main features of the used typeface which influence the legibility of a typeface. The first and most obvious one is recognizability.
It a feature that mainly relates to individual letters. We recognize a letter if we have learned an abstract model of its shape-usually by being exposed to thousands of variations of it and by having learned to write it. Humans are exceptionally good at this kind of tasks. Even if the actual outline or image of the letters might be completely different in every font or written text, we are still able to easily decode the underlying design principle, thus we are able to decode the letter.
It is therefore noteworthy, that the actual design of the character outline (in terms of stroke width, serifs and so on) plays a minor role in this basic sense of recognition. What matters most is the actual design principle or the skeleton of the letter. And therefore, it must be considered a myth that serif typefaces are more legible than sans-serif typefaces when they share a similar letter skeleton.
A legible typeface is therefore one, that aids recognition by using a rather generic letter skeleton the readers are familiar with, no matter if that typeface has serifs or not.
An additional legibility feature of typefaces is distinguishability. It's the characteristic of a letter to be easily told apart from other letters. The one-storey "a" of Avant Garde or Futura might be perfectly fine in terms of recognition. These letters have a very simple and generic skeleton and can easily be recognized in contexts like magazine headlines. But when viewing conditions get worse or when we quickly read longer text and therefore skip many letters, distinguishability becomes crucial.
Take these letters from the Swedish road sign font Tratex. Apart from their descenders they are completely identical and this slows down letter decoding under poor viewing conditions. For example drivers reading road signs might easily confuse an "a" for an "o" or vice versa when viewing the sign at a large viewing distance or when the letters are lit by the headlights of a car.
Now let's look at the same letters in a different typeface. In this case, letter differentiation is stressed thru a more individual, yet well known letter skeleton. So such kind of typefaces have a much better distinguishability, which might or might not be necessary in different kinds of typesetting tasks.
So far, I have mostly talked about the skeleton of letters and not about stylistic differences. So what about them? Do serif typefaces like Garamond and Bembo do have any advantages over Helvetica and Frutiger if it all depends on just letter skeletons? The typographic literature usually just mentions the supposed fact, that serif typefaces are somehow better or "more legible" because the serifs guide the reader along the line of text. There is probably some truth in that, but I always found it hard to believe, that this should be the only and most important reason why after 500 years we still set most of our books in serif typefaces.
To explain this phenomena, my model introduces the term reading comfort. It describes subtle features of a typeface, that are not directly related to recognizability and distinguishability. But these features make it possible to read even long texts with as little distraction and fatigue as possible. And that's where the type design styles of the Renaissance and Baroque are so good at, because they were developed specifically for this kind of typesetting.
For an experienced reader, the task of reading is mostly automatic. It is basically impossible not to read a word we see in front of us. But still, reading long texts is a cognitively strenuous exercise. Reading is not an evolutionary ability that developed over tens of thousands of years. We simply use (or misuse) our highly developed ability to schematize the world around us-in this case: to use abstract images to represent sounds.
While some typefaces might perform well in terms of recognizability and distinguishability, they might not necessarily be suited for setting a novel in it. The clean sans-serif typefaces of today often sacrifice reading comfort for even typographic color and the possibility to set large amounts of text within as little space as possible. The stems of these typefaces then become endless rows of "picket fences", which can easily cause fatigue. But variance in stroke and letter width can make the process of reading more pleasant and comfortable. We all know, how tiring a sheet of paper in a monospaced typeface can be. This is caused by the missing variance of the character widths. A typeface suitable for longer text will stress variance in letter design and character width. This influences how the letters and word shapes are perceived outside of the fovea-the small part of a line of text that we can actually see sharp and detailed. This helps to perform effective saccades, to understand the structure of the sentence and to anticipate the following words.
So now our model is complete and it allows us to easily talk about different aspects of reading and legibilty. Now it also easy to answer the question, why road signs are set in sans-serif typefaces and novels in serif typefaces. If we talk about signage, we just need to consider the upper half of the model. The textual information need to be presented in a legible way and set in a typeface which letters are both recognizable and distinguishable. That's it! The features of a typeface that aim at reading comfort are not necessary when just short pieces of information are presented. On the other hand, if we want to set a novel, all layers must be considered.
This image shows some typical uses applied to the model. For a headline, we need a legible layout set with recognizable letters. Distinguishability and reading comfort are certainly dispensable. Signage requires a much more careful layout using typefaces that are optimized for recognition and letter differentiation. Copy texts require all layers to be considered carefully. We need a legible type setting and the letters of the typeface should not only be recognizable and distinguishable, but also comfortable to read over many paragraphs or pages.
Actual and Prospective
Lapin yliopisto, Rovaniemi
CORE, Tampereen yliopisto
How to communicate with shared common spaces?
Since the middle of the past century, the technical development of our means of transport and associated facilities has expanded to a degree that it is becoming more and more complicated to use. People are more mobile than ever before: they travel from one town to another, from one country to another and from one continent to another, and for this they require instructions for use which suit the particular function. This includes a universally comprehensible supply of information which is located in the centres of public transport and not only indicates the routes to and from the transport facilities and provides guidance within those centres, but also gives instructions on how to use the transport facilities themselves.
"Elevator" pictograms: AIGA · ERCO · Japan · Heiko Barmbold · Heiko Barmbold · City of Bruges (BE) · Hansgrohe AG · ISO 7001
The increasing growth of civil aviation in the 50s led the International Civil Aviation Organization (ICAO) to comply all typographical signs and issued a study to the needed international requirements of a pictural language understood by various ethnic groups. The sense of orientation alone is no longer enough to find your way in an international airport, also the reception of pictorial, graphic, written and spatial signals is needed. The goal of airport signs & wayfinding systems in airports is to show visitors their way. From finding the toilets, gates, tranfsers or even the coffee corner. Creating a wayfinding system in a airport which will have to guide thousands of visitors takes a in-dept case study of the visual environment, travellers stream, detailed prints of the building and much more.
ERCO pictogram: º 0165: "Passenger"
But the freeze-framed gestures based on the western way of thinking are often insufficient for international public. The diversity of languages is increasing. The "Council of Graphic Design Association" (ICOGRADA) was to promote international projects for the unification of icons. The "symbol plan" of the United Nations started in 1964 with the call for international and obligatory usage of formulated symbols. "The American Institute of Graphic Art" (AIGA) in cooperation with the US Department of Transportation developed internationally recognizable characters which require legibility in varied global cultures and age groups. The International Organization for Standardization, (Geneva), ISO, arranged worldwide test series for the appraisal amongst scientific criteria of the optimal expression in the character in the way of semiotic and pychology of perception. The organisation is monitoring the standard ISO 7001, the standardized "graphic symbols for public information." In ISO 9186 are all procedures and criteria for assessing and reviewing the comprehensibility of pictograms fixed. To achieve successful passenger orientation, an evaluation of the ease of passenger orientation in the terminal is necessary. It is recognized that the success of the passenger's ability to locate a facility can be based on a visibility index. Orientation is more than just hang signs and better signage doesn't just mean better looking signs. Pictograms are supposed to be self-evident, but they produce doubt. The freeze-framed gestures need also knowledge of the western way of thinking.
"Apothecary, pharmacy": ERCO (0068 Apotheke) · Pharmacy Fairbury · Medicine (Colorado) · Apotheke (Austria) · Apotheke (Germany)
Differences in wayfinding behaviours between gender, age group, type of travel group and level of familiarity with the environment are identified. Females tend to follow a crowd and are more likely to use wayfinding strategies such as Least Time, First Noticed, and Different from Previous Route Taken than males. Males are more likely than females to use Vegetation Types and Track Surfaces as their wayfinding landmarks, and they prefer Most Scenic wayfinding strategies.
Vitruvius defined the qualities of architecture in his famous book: »De architectura« (1st century BC) that a structure must exhibit the three qualities: firmitas (we might translate as durability), utilitas (functionality) and venustas (beauty). On the one hand, I attempt these qualities into a practical formula to indicate the precise mix of qualities required (Mijksenaar, 1997):· reliability (trustworthiness),
· utility (practicability),
in international airport signposting.
"Departure": Ольга Куликова, МХУПИ (Moscow Art College of Applied Arts and Academy of Graphic Design)
On the other hand is a passenger as described by ACI (Airports Council International) is someone who arrives in, departs from, or transfers through an airport. The passenger journey in an airport can be represented as a flowchart, it has usually a "Start" and an "End" and it has a conditional or decision part, where the signs/directions inside the terminal play the parts of a crucial role.
Example: flowchart representing a process
Are we able do express complex instructions, or are those pictural representations not necessarily easyier to understand than a written expression. The power of our visual material is limited (based on Liesbet Zikkenheimer's visualisations spectrum).
Visualisations spectrum by Liesbet Zikkenheimer
And the graphical material itself is limited to seven visual variables: position, form , orientation, color, texture, value, and size; (according to Jacques Bertin). For better understanding the visual perception of guidance- and orientation systems we use the triadic relationship between physical signs, the objects to which they refer, and the human interpreter. The sign made up of a signifier or sensory pattern, and a signified, the concept that is elicited in the mind by the signifier, accordingly more detailed in Umberto Eco's model of communication (Eco 1995, . 123).
Ignored cultural semiotics?
Was it a mistake when ISO - International Organization for Standardization had defined the present existing worldwide set of icons and related functions, not paying attention to cultural semiotics. Does this indicate a needed change in our cross-cultural communication and does it show a turning point in our future development of the arsenal of iconographic, geometric, linguistic and formal conventions to mediate spatial information into pictorial representation?
"das allgäu" (bei isny) by Otl Aicher, detail from the booklet for the Allgäu region (German region in the southwest of Bavaria)
Investigation of the process of orientation in shared common spaces as well as investigation of the individual interpretation of given pictographic (iconic) information in cultural context. Developing a critical attitude towards existing orientation and information systems. Examination of the iconographic particularities of orientation systems and their demands on the recipients. According to existing flow charts which show the designated processes on an airport and highlight where the system's points are and where a passenger expected is to go from each point.
"Restaurant" pictograms: 国标代码 LB/T 001-1995 (China) Western Restaurant
We have to change the tools for environmental graphic design to create a well-functioning communication. With the focus on visual communication we have to factor also pervasive mobile applications into consideration. We need to overhaul the pictographic expressions. We should take as the standard the one symbol which does communicate the intended meaning most readily to most people.
»Standard Isotype System« by Ravi Pooahaiah, Industrial Design Centre (IDC) at IIT Bombay, India. »Office« 0445 by ERCO
The research work is in the range of visual perception, perception psychology of guidance- and orientation systems in public-space and buildings and will challenge the semantic and semiotic function of the used signs as well as their effectiveness. In the study series, the signs of the thirty world's busiest airports, measured by number of total passengers traffic (data provided by Airports Council International) will be examined. The signposts used there will be taken out of their context and examined in an international online survey on the three specified grades: reliability · utility · satisfaction. A great advantage of this investigation: it is not susceptible to the kinds of dogmas that may arise from the interpretation of functionality and/or design sensitivities. An international evaluation will create several valuation models for one and the same character to determine patters, which allows to detect weaknesses that would otherwise not be visible under the specified methods for testing the comprehensibility of graphical symbols like in ISO 9186-1 and 2:2007. Combined with the analytical investigation of the intersection in the flowchart of passenger movements in an airport gives us information about the semantic relevance of the signpost and its basic necessity.
Investigation of the semantic relevance of an existing pictogram:
(ωi | )
First findings of an investigation in visual communication in public spaces on the one hand at üsseldorf International Airport (Germany) made obvious the locations of all shops and restaurants are difficult to find, spatial guidance is hidden for inattentive passenger. With my students onsite my lectures »Environmental Graphics« at the University of Lapland on the other hand we developed different case scenarios and had an exploratory look revealing the path taken by individual persons. Gathering that information, combining with new developed research will educe my thesis to design sign systems and strategies for a more effective way to direct humans in public space.
A newer (and perhaps clearer) version of this document has been published as Unicode Technical Note #22: Robust Vertical Text Layout. An HTML version is provided here.
Few formatting systems today can handle vertical text layout, and most of those only lay out text in right-to-left columns. This document outlines a system that can not only handle common scripts in vertical right-to-left columns, but that can gracefully accept uncommon script combinations and left-to-right text columns. The model is described here as a CSS system, but the concepts can apply to non-CSS systems as well.
The CSS model and Unicode provide support for logical text layout, but only in horizontal flow. Although CSS3 Text attempts to use horizontal BIDI controls to handle vertical BIDI, the system it sets up is ill-defined and inflexible, relies on assumptions that may not hold true, and requires a styled document's content and its markup to be adapted to the CSS rather than the other way 'round. A better design would use the intrinsic properties of the characters and an expansion of Unicode's logic to lay out the text. A layout model thus based on the logic and knowledge of writing systems can scale to gracefully handle any combination of scripts, can correctly (if not optimally) lay out text with any combination of styling properties, and can integrate well with the layered Unicode + Markup + Styling model of semantically-tagged documents.
The examples in this text require support for Unicode BIDI and Arabic shaping, and fonts for Simplified Chinese and Arabic/Farsi. Most diagrams are available in SVG, but inline versions are in PNG with fallbacks in GIF.
Recommended browsers (recent versions):
- Gecko-based (such as Mozilla, Firefox, or Camino (Mac OS ))
- Microsoft Internet Explorer or Safari may suffice.
- Misuse of Directionality and Its Consequences: A Case Study of CSS3 Text
- Describing Text Flow
- Implementing A Logical Text Layout System
- Why and How the Unicode Consortium Should Be Involved
- About the Author and the Status of CSS3 Text
- Appendix: Vertical Scripts in Horizontal Flow
Unlike many formatting systems, in which styling properties are definitively applied to a page element at one point, CSS collects and applies to the element multiple style rules from the author, reader, and user agent. In case of a conflict, the origin of the rule and the specificity of the rule's element selector determine which of the conflicting property values takes effect on the element. This process of sorting and applying style rules is called cascading, and it allows style rules from multiple sources and with separate formatting purposes to interact in a rigorous way.
Cascading means that style properties specified together are not guaranteed to take effect together. This raises the design standards for creating CSS properties and pushes them towards a more logical, rather than physical, description of the intended design.
CSS2 introduced the
unicode-bidi properties to incorporate markup directives such as HTML's
dir attribute into the CSS rendering model, and to allow the use of markup semantics in assigning BIDI embeddings. The
direction property can take the values
rtl, and this value inherits to descendant elements. The
unicode-bidi property assigns embeddings and overrides in the direction given by the
direction property. Its behavior is defined in terms of the Unicode embedding and override codes.
When applied to a block of text, the
direction property specifies the block's embedding direction; CSS documents do not use heuristics to guess the block's embedding direction.
These properties are meant to reflect BIDI distinctions necessary for the proper ordering of text. Authors in general are discouraged from using the properties in favor of the direct markup that would trigger the appropriate values.
CSS3 Text was intended to update and expand the text layout capabilities of CSS2 by adding support for more international typesetting features and introducing controls for laying out vertical text. It defines a
block-progression property, which switches the line stacking direction, and hijacks
ltr values of the
direction property to use as an inline-progression control in vertical text.
writing-mode: direction: block-progression: Common Usage: lr-tb ltr tb Latin-based, Greek, Cyrillic writing systems (and many others) rl-tb rtl tb Arabic, Hebrew writing systems tb-rl ltr rl some East Asian writing systems tb-lr rtl lr Mongolian writing system
It is a good example of how not to set up a vertical text system.
In order to interface with the Unicode BIDI Algorithm, CSS3 Text maps vertical scripts' character directionality based on the paragraph's block progression.
Because all vertical scripts in Unicode are assigned a canonical directionality of left-to-right, BIDI reordering proceeds as normal when the text columns are stacked right-to-left.
However, if the columns of text are stacking the other way-from left to right-then the same characters (which so far are all given left-to-right directionality in Unicode) are treated as right-to-left characters (
R). This was done because left-to-right scripts such as Latin read bottom to top when the lines of text were ordered left to right. In this case, top-to-bottom scripts must go in the direction opposite the left-to-right text, and the opposite of ltr is rtl.
Messing with the directionality of vertical scripts messes with other bits of text layout as well, and much of this interaction was left undefined. Character shaping, for example, depends on the BIDI-reordered string being in normal order. Not only character ordering, but the character shaping algorithm and the font rendering code all need to compensate for the altered input to the BIDI algorithm, and CSS3 Text failed to explain the necessary changes.
For example, Mongolian is a cursive vertical script. Like Arabic (to which it is related), it is also a shaping script: a letter at the beginning of a word is shaped differently from one in the middle or at the end. Unicode defines Mongolian to be a left-to-right script, so shaping makes the leftmost character of a word into an initial and the rightmost character into a final. If, however, the Mongolian word is ordered right-to-left, then the initial letter of the word will be on the right, and therefore shaped as a final and not an initial. This is because shaping happens after reordering. Vertical Mongolian text treated like this will look upside down and read like a bunch of gibberish, and no amount of glyph rotation can fix the problem. To make the letters connect properly under the CSS right-to-left override, the Mongolian parts of the text would need to be shaped in reverse and then have their glyphs rotated 180°-but this is not even mentioned in CSS3 Text.
To accomodate CSS3 Text's ill-defined tweaks to BIDI reordering (and character shaping and font rendering), a layout system can't simply pass the string to standard Unicode processing functions. Assume, however, that the layout system manages to hold up internally the pretense that "top-to-bottom" is "right-to-left". It still needs to interact with BIDI instructions from the outside world, which doesn't share the delusion. In an effort to make the outside world seem like it's adapted to these changes, CSS3 Text instructs the designer to use
direction: rtl when assigning
block-progression: lr to a block of top-to-bottom text (such as Mongolian or Chinese, both actually
ltr scripts), in effect asking him to lie about the text's properties. Like most lies, it seems to work in the general case, but as the situation gets complicated, the system breaks down...
Foremost, if the expected block progression fails to take effect-whether through the cascade or through lack of UA support-the text direction and the assigned embedding direction no longer match and the subtleties of Unicode BIDI can wreak havoc on the order of the text.
<p style="/*block-progression: lr;*/ direction: rtl"> (这是)一些中国字. </p>
BIDI control characters placed by the content author to order horizontal text are now affecting a topsy-turvey set of character directionalities.
In this sequence:
在这个对话, بهار 告诉 الیکا : این کتاب را به برادرم ببر و برایش بخوان.
The punctuation in the middle is given as "thin space", "colon", "space". The punctuation sequence is surrounded by some rtl text on one side (ندا) and an rtl embedding (the quotation) on the other. If left alone, the thin space and the colon will join the Persian name and the quotation in single right-to-left sequence, like this:
在这个对话, بهار 告诉 الیکا : این کتاب را به برادرم ببر و برایش بخوان.
The text's author (or the authoring software) was intelligent enough to insert two left-to-right (
LRM) marks around the punctuation sequence so that this does not happen.
If, however, this Chinese paragraph is treated as rtl when put in a vertical context, then the punctuation sequence will be ordered the wrong way. (It will still be left-to-right because of the codes, instead of right-to-left like the rest of the text.)
CSS embeddings set on elements within the formatted block are no longer necessarily going the right way.
This bit of code assigns the wrong directionality if the text is to be inserted in a page with vertical text layout settings that make Chinese pretend it's rtl.
dirattributes that were added with the assumption of regular, horizontal text might or might not need to have their effects be reversed.
<p dir="rtl">وسط این خملة فرسی, <q dir="ltr">在中国(PRC)人民用人民币.</q> یک خملة چینی هست</p>
وسط این خملة فرسی, 在中国(PRC)人民用人民币. یک خملة چینی هست
If this paragraph finds its way into a left-to-right block progression, the Chinese quote will need a right-to-left embedding to match the CSS-altered directionality, not a left-to-right one.
There is no mention of how character shaping should happen.
In conclusion, abusing directionality controls to make a limited system lay out text correctly doesn't scale. It's a hack, not a solution.
To describe how a text flows into lines, one needs to know three things:
- which way the text flows within a line (inline progression)
- which way the lines stack (block progression)
- which way the glyphs are facing (glyph orientation)
However, not all combinations of text direction and glyph orientation are valid. Therefore if certain of the character's inherent characteristics are known, it is often possible to derive one from the other. Unicode systems take advantage of this model in horizontal text: you don't have to manually tell every run of Hebrew to order itself right-to-left, and you don't need to specify that Mongolian characters turn themselves sideways when the text is running horizontally left-to-right.
In a purely physical layout scheme, each of these text layout properties would be given as an absolute: The inline progression of this run of English is top to bottom, its glyph orientation is 90 degrees clockwise, its block progression is from right to left. However, because the interrelationships among these properties are realized in the author's mind and not in the system,
- The author must manually intervene any time there is a script change.
- If one of the three properties fails to take effect (because of the Cascade or lack of UA support), then the layout breaks and the text becomes unreadable.
A better system would embed knowledge of different scripts' intrinsic characteristics and define style properties in terms of the relationships among them.
Each script has a characteristic writing direction, and each character in Unicode is assigned a directionality value based this characteristic. Unfortunately, Unicode currently only defines horizontal directionality even though vertical and bi-orientational scripts have a vertical directionality as well. For example, while English can go either top to bottom or bottom to top (since it doesn't have a vertical directionality), Japanese must only go from top to bottom, even in a left-to-right block progression. Mongolian also has top-to-bottom vertical directionality. Unlike Japanese however, it has no definite horiziontal directionality (just a canonical one for BIDI purposes).
Scripts can be classified into three orientational categories:
- Scripts that have horizontal, but not vertical, directionality. Includes: Latin, Arabic, Hebrew, Devanagari
- Scripts that have vertical, but not horizontal, directionality. Includes: Mongolian, Manchu
- Scripts that have both vertical and horizontal directionality. Includes: Han, Hangul, Yi, Ogham
Bi-orientational scripts may be further classified by how their glyphs transform when switching orientations. CJK characters translate; they are always upright. Other scripts, such as Ogham and some variants of classical Yi, must be rotated.
Scripts in their native orientation need no additional stylistic hints for proper layout: their inline progression and glyph orientation are both intrinsically mandated, so the style system can know by itself how to lay them out. Directionality and glyph orientation overrides are not necessary and should not be used. (In fact, using them degrades the system by creating a tangle of dependencies, as demonstrated in the section on the current version of CSS3 Text.)
Scripts in a foreign orientation don't need directionality or glyph overrides either. They just need a few hints: whether to translate upright, or, if they're rotated sideways, which side is "up". Given that, the rules for laying out the text in its native orientation are enough to determine the inline progression and exact glyph orientation.
For scripts in a non-native orientation, the natural inline text flow depends on the direction of line stacking: the text is most comfortably laid out as if the whole text block were merely rotated from the horizontal. For example, English text in vertical lines that stack from left to right will face with the glyphs' tops towards the left and the text direction running from bottom to top. The same text, by the same logic, would in a right-to-left line stacking context face right and flow within each line from top to bottom.
Merely rotating the rendered text from a horizontal layout is not sufficient because while the primary script is horizontal, it may include some vertical text (such as Chinese) that would need to be laid out appropriately for vertical lines.
Putting this logic into the style system is straightforward: define "up" for non-native glyphs to point to the beginning of the line stack, and the inline progression follows from that orientation. The glyph orientation and inline progression will thus adapt to whichever block progression happens to take effect.
This layout scheme is most appropriate for dealing with text that has been turned on its side for layout purposes-as for page headers or captions or table headings. However, a major use case for laying out text in a non-native orientation is mixing horizontal and vertical scripts, which introduces the requirement of making the secondary scripts flow well in the context of the primary script.
For example, a primarily Mongolian document, which has vertical lines stacking left to right, usually lays its Latin text with the glyphs facing the right. This makes the text run in the same inline progression as Mongolian and face the same direction it does in other East Asian layouts (which have vertical lines stacking right to left), but the glyphs are facing the bottom of the line stack rather than the top, something they wouldn't do in a primarily-English paragraph.
Yet another common layout is to keep the horizontal script's glyphs upright and order them from top to bottom; this is frequently done with Latin-script acronyms in vertical East Asian text.
To handle these layouts, the style system needs to offer controls for choosing among these different layout schemes. Note, however, that scripts in their native orientations do not need these hints; only the non-native ones do. Also, this is only one simple scheme switch here: there's no need for the designer to set separate absolute inline progression and glyph orientation controls or to set styling properties on each text run of a different script.
In summary, to lay out a block of arbitrary, mixed-script text, the layout system needs to offer only three controls:
- primary script's directionality (BIDI property)
- block progression direction (stylistic property)
- glyph orientation scheme (stylistic property)
Formalized into CSS syntax, this becomes:
Primary directionality. Can take the following values
- Left-to-right directionality in horizontal text; No inherent directionality in vertical text. (Horizontal script) Examples: Latin, Tibetan
- Right-to-left directionality in horizontal text; No inherent directionality in vertical text. (Horizontal script) Examples: Arabic, Hebrew
- Top to bottom directionality in vertical text; No inherent directionality in horizontal text. (Vertical script) Example: traditional Mongolian
- Left to right directionality in horizontal text; Top to bottom directionality in vertical text. (Bi-orientational script) Examples: Han, modern Yi
- Left to right directionality in horizontal text; Bottom to top directionality in vertical text. (Bi-orientational script) Example: Ogham
Block progression (line stacking) direction. Can take the following values
- Top-to-bottom line stacking (horizontal text). Typically used for most non-East-Asian layout.
- Right-to-left line stacking (vertical text). Typically used for traditional CJK layout.
- Left-to-right line stacking (vertical text). Typically used for traditional Mongolian layout.
Glyph orientation scheme to use in vertical text. Can take the following values
- Non-vertical script runs are laid out as if "up" was towards the top of the line stack (left or right, depending on the block progression in effect). (Vertical scripts are laid out as vertical scripts.)
- Non-vertical script runs are laid out as if "up" was towards the left side of the line stack. (Vertical scripts are laid out as vertical scripts.)
- Non-vertical script runs are laid out as if "up" was towards the right of the line stack. (Vertical scripts are laid out as vertical scripts.)
- Non-vertical scripts' characters read top to bottom, with each grapheme cluster oriented upright. (Vertical scripts are laid out as vertical scripts.)
For handling vertical-only scripts in horizontal layout, a
text-orientation-horizontalproperty is also necessary; it takes effect only when the block progression is top-to-bottom. To keep the discussion less verbose, I am relegating consideration of horizontal layout to an appendix.
As long as the directionality is set correctly for the text (and it should be set automatically from the content/markup as long as the designer doesn't touch it later), any combination of the block-progression and text-orientation stylistic values will result in a correct (though perhaps not optimally-designed) text layout.
The style system can thus handle most of the intricacies of laying out both usual and unusual combinations of text by itself. What it needs to do this, however, is to know the intrinsic properties of the characters and the logic of laying them out.
Handling block-progression is very straightforward: just stack the composed lines in the stacking direction. Composing the lines of text is more complicated. The text needs to go through three processing steps.
Character ordering is where the BIDI algorithm gets applied. The algorithm remains essentially unchanged when dealing with vertical text: what changes is the data. Specifically, the directionality values of certain characters are mapped into the algorithm differently depending on the styling context.
The Unicode Bidirectional (BIDI) Algorithm deals with two directions: left-to-right (towards right) and right-to-left (towards left), defined to be the same as the script directionalities involved. Although this multi-directional model has several more directionality values, the BIDI algorithm here still deals with only two directions: it just abstracts them so that they could just as easily be bottom-to-top (towards top) and top-to-bottom (towards bottom). To avoid the apparent absurdity of mapping right to left and such things, I will call the two BIDI directions "high" (H) and "low" (W). (Implementations, no doubt, will prefer to call them "left" and "right" to map directly into the Unicode BIDI algorithm.)
It is important to keep in mind that these directions are abstract. We will map "left", "right", "top", and "bottom" to "high" or "low" based on the values of
block-progression. The mapping applies to everything: the individual character's directionality, embedding and override codes, the CSS
direction values, HTML
dir attributes, etc. Once the line is composed, we then lock "high" and "low" to the appropriate sides of the block as we stack the lines according to
Directionality Mapping: Vertical Case
In vertical context, bi-orientational scripts use their vertical directionality and behave as vertical, not horizontal, scripts. Han, for example, as a
ltr-ttb script, is treated as
ttb (top to bottom), not
ltr (left to right). The
ltr-ttb value for
direction is correspondingly treated the same way as the value
text-orientation: right (and
text-orientation: natural in a right-to-left block progression)
htl(high to low)
lth(low to high)
Run the Unicode BIDI Algorithm with its "left" being our "high" and its "right" being our "low".
text-orientation: left (and
text-orientation: natural in a left-to-right block progression)
lth(low to high)
htl(high to low)
Run the Unicode BIDI Algorithm with its "left" being our "high" and its "right" being our "low".
Before the system can paint the text (or even do alignment), it needs to know how to rotate the glyphs. For vertical and bi-orientational scripts, this is simply "rotate me to my intrinsic position". This doesn't mean "don't rotate me, I'm supposed to be upright", however, because the standard representation of a character in a font is the one used in horizontal text.
Han and Kana and Hangul and Yi do need to be kept upright (0° rotation) because they use the same orientation in both horizontal and vertical text. Mongolian (and Ogham), however, rotate from one context to the other and so their glyphs must be rotated 90° from their horizontal orientation when used in vertical context. Part of the system's knowledge, therefore, needs to be which scripts need to be rotated and which merely translated into place. Given that and the script's directionality, the exact rotation can be derived as follows:System's Knowledge of Vertical Scripts' Properties
|(cannonical) horizontal directionality|| || || |
|vertical directionality|| || || |
For horizontal scripts, the method is "rotate me according to the relevant text-orientation style".
text-orientation: right or
text-orientation: natural in a right-to-left block progression:
Rotate horizontal scripts' grapheme clusters 90° to the right.
text-orientation: left or
text-orientation: natural in a left-to-right block progression:
Rotate horizontal scripts' grapheme clusters 90° to the left.
Keep glyphs for horizontal scripts upright and stack grapheme clusters vertically.
Transformations for punctuation, being somewhat arbitrary and stylistic, should be handled by using vertical glyph variants given in the font, but only when the
direction of the text is a vertical or bi-orientational directionality or
upright. (If the text is primarily horizontal text rotated sideways, then the punctuation should likewise be horizontal punctuation rotated sideways.)
Character shaping is the process of selecting, based on context, which of several allographs of a letter should be used. This is typical of cursive scripts like Arabic and Mongolian, where the shape of a letter depends on whether it comes at the start of a word, in the middle of a word, or at the end of a word.
According to UAX 9, character shaping occurs after BIDI reordering: the Arabic character shaped as an "initial" will always be on the right, even if the text is given a left-to-right override. This ensures that the letters always connect. (An initial form on the left side of the word would be trying to connect to nothing.)backwards shaping, correct shaping -->
To deal with the multiple orientations of vertical layout, the shaping logic needs to know not just the reordered string of characters, but which side of the line is "up". If we turn the glyphs all upside-down, for instance, the shaping needs to be done in reverse. Because in vertical text Arabic and Mongolian can go in the same direction or in opposite directions, merely inverting the entire character string before passing it to standard Unicode shaping functions doesn't work.
Shaping occurs only within each directional level run. Shaping is also constrained to runs of text in the same script; Mongolian characters, from Arabic's point of view, form as concrete a boundary as Latin ones do. It is therefore possible to break up the text into pieces that have characters from no more than one shaping-affected script without compromising the accuracy of the shaping. Then, for each run of text, one can use the shaping script characters' glyph orientation (derived above) to determine which way is "up" (0°) and hence which are the "left" (-90°) and "right" (+90°) sides of the text run. Once that's known the text run can be shaped, in reverse if necessary.
In addition to knowing the text, its primary directionality, and its styling properties, the implementation needs to know something about the characters themselves to be able to take advantage of the logical model. For each character, the following information must be available to the text layout algorithm:
- horizontal directionality:
For vertical scripts this means the canonical directionality that is used for fonts and for plaintext horizontal layout.
- vertical directionality:
For horizontal scripts, this is
- glyph transformation between horizontal and vertical orientations:
Only applies to scripts with vertical directionality.
Unicode only specifies the horizontal directionality. For some scripts (not all), vertical directionality can be gleaned from the prose chapters describing the different writing systems. Glyph transformations are not given at all, only implied.
Why and How the Unicode Consortium Should Be Involved
The text layout model outlined in this document adds to the scope of the Unicode BIDI Algorithm and requires additional knowledge of character properties. This expansion should be part of Unicode rather than an alteration defined in CSS3. Standardizing it at the Unicode level rather than at the CSS level is more appropriate because
- The Unicode Consortium has the expertise necessary to specify the character data correctly even for obscure scripts.
- The extended data and algorithms operate at the same level as the existing Unicode specifications.
- Non-CSS systems wanting to use this model will have a solid base to work off of rather than having to adapt bits of a high-level protocol (CSS3) to fit their application.
- Standard Unicode APIs can be designed to handle the extended BIDI and shaping manipulations so that each application will not need to implement all of that itself.
- Intermediary systems such as HTML can accomodate the model by building up from Unicode rather than down from CSS. (HTML would need the new
directionvalues for its
- Unicode can add character-level support for vertical-directionality by defining directionality control codes to correspond with the vertical directionality requirements. This will allow the same plain text to be properly flowed into vertical layout contexts as well as horizontal ones.
I will be including the results of my personal research as a normative appendix to the next revision of CSS3 Text. Should the Unicode Consortium provides the necessary character data, I will publish a new version that removes the appendix and instead references the relevant sections of the Unicode Standard.
I am an invited expert for the CSS Working Group at the World Wide Web Consortium (W3C) and the new editor of the CSS3 Text module. I intend to completely rewrite the Text Layout chapter for the next version of CSS3 Text based on the principles outlined herein.
Thanks go out to:
- Martin Heijdra at the East Asian Library, for his guidance, expertise, and enthusiasm. I had never imagined that the bibliographer helping me find books would turn out to be an expert on international typography and Mongolian in particular.
- Ian Hickson, the members of the www-style mailing list, the members of the CSS Working Group, and the contributors to the Mozilla Project for tempering my technical skills and CSS knowledge over the years
- The CSS Working Group for giving me a chance to fix everything I found wrong in the CSS3 Text drafts.
- Last, but not least, åkon Wium Lie and Opera Software for supporting me in creating this work, to the point of even paying me to finish it. I only wish it hadn't taken so long so that I could spend more time on QA. ;)