Re: vertical direction control
On 24/03/2004 15:08, Asmus Freytag wrote: ... Let me rephrase it: I don't think I know of a scenario where it is critical for a resource limited device to support the selection of vertical vs. non-vertical display of text. Unless there is some such scenario, there's no need to even speculate about alternatives to existing markup languages. I have not seen a credible scenario. What about a cell phone or PDA for use in China. Some users may prefer vertical display of text, but then the system needs to know what to do with Latin etc text embedded in the Chinese. Isn't that a credible scenario? Or are the Chinese to be forced to read their language horizontally on all electronic devices? -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: vertical direction control
On 24/03/2004 17:40, Doug Ewell wrote: Peter Kirk peterkirk at qaya dot org wrote: And surely Braille could equally be considered a cipher of Latin script (although the same symbols are also used as a cipher of other scripts). ... which is one reason it can't be considered just a cipher of Latin. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ Well, we went through this one some months ago. There is a script, I've forgotten its name, which is used as a cipher of Latin script and with the same glyphs as a cipher of Hebrew script. Does that imply that this script is not a cipher and so separately encodable? -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: vertical direction control
On Thu, 25 Mar 2004 03:36:29 -0800, Peter Kirk wrote: What about a cell phone or PDA for use in China. Some users may prefer vertical display of text, but then the system needs to know what to do with Latin etc text embedded in the Chinese. Isn't that a credible scenario? Or are the Chinese to be forced to read their language horizontally on all electronic devices? The whole point is that you cannot sensibly mix vertically formatted text and horizontally formatted text in the same line (except for the case of very short words). When Mongolian text is embedded in Latin, Cyrillic or horizontal Chinese it is rotated 90 degrees so that it reads LTR instead of vertically; and when Latin or Cyrillic text is embedded in vertical Mongolian or vertical Chinese text the alphabetic script is normally rotated 90 degrees so that it reads TTB instead of LTR. There is absolutely no need for directional formatting controls in these situations. The only potential need for vertical formatting controls would be if you were embedding a chunk of Bottom-To-Top text within text that was oriented Top-To-Bottom (or vice versa), but that scenario is extremely unlikely, and even if it did occur you could simply use the horizontal formatting controls (LRO, RLO, PDF, etc.) - treating TTB as LTR and BTT as RTL - and use a higher level protocol to rotate the whole thing 90 degrees. Andrew
Re: vertical direction control
It seems strangely inconsistent to me that Unicode has detailed controls for horizontal layout direction and the complex bidi algorithm, but has nothing for vertical layout. I can force Latin text to be rendered right to left or Hebrew left to right (although such overrides are hardly plain text issues), but there is no way I can select vertical layout even for languages in which that is a normal way of writing. We already have U+202A LEFT-TO-RIGHT EMBEDDING and U+202B RIGHT-TO-LEFT EMBEDDING. It would be easy to define new characters TOP-TO-BOTTOM EMBEDDING and BOTTOM-TO-TOP EMBEDDING, with similar scope until the next PDF character. Which scripts are written bottom to top in vertical layout? If I remember well then both latin and hebrew script are written top to bottom.
Re: vertical direction control
Chris Jacobs scripsit: Which scripts are written bottom to top in vertical layout? The native direction of Ogham is bottom-to-top, although it is rotated to left-to-right when it has to coexist with Latin. There presumably is no traditional method of setting Ogham with Han-influenced scripts, although doubtless Michael will be able to design something suitable for a nominal fee. ;-) -- John Cowan [EMAIL PROTECTED] www.ccil.org/~cowan www.reutershealth.com I must confess that I have very little notion of what [s. 4 of the British Trade Marks Act, 1938] is intended to convey, and particularly the sentence of 253 words, as I make them, which constitutes sub-section 1. I doubt if the entire statute book could be successfully searched for a sentence of equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940
Re: vertical direction control
Mike Ayers wrote: Do you have examples of cases where vertical control has content? I thought there were no such cases known. U+3031 and its voiced variant U+3032 are only appropriate to use in vertical layout. These two characters are AFAIK only used in Japanese, and the current recommendation is not to use them at all. Unicode contains doubles of some CJK punctuation marks, one form for vertical layout and one for horizontal layout. It is inappropriate to use a vertical punctuation mark in horizontal writing, and vice versa. I wonder why this was not solved in the same way as with LTR/RTL, where some characters, e.g. parantheses, are mirrored when changing the reading direction. In CJK this is a matter of turning the characters 90 degrees. Stefan
RE: vertical direction control
Which scripts are written bottom to top in vertical layout? The Unicode bidi faq tells that ancient Numidian was written bottom to top, and the Egyptian hieroglyphics could go basically in any direction. Then again, it also says that developers shouldn't really worry overmuch about these. If I remember well then both latin and hebrew script are written top to bottom.
RE: vertical direction control
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Persson Unicode contains doubles of some CJK punctuation marks, one form for vertical layout and one for horizontal layout. Only so for backward compatibility with legacy standards. For instance, apart from legacy compatibility, there is no reason to use FE35 in Unicode-encoded text: a rendering system can rotate 0028 when laying out vertical text. Peter Peter Constable Globalization Infrastructure and Font Technologies Microsoft Windows Division
RE: vertical direction control
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Kirk It seems strangely inconsistent to me that Unicode has detailed controls for horizontal layout direction and the complex bidi algorithm, but has nothing for vertical layout. The bidi embedding and overrides are needed to maintain legibility of the text is certain situations. Orientation controls for CJK text are not needed to ensure legibility. For instance, given an encoded sequence a, b, c, space, D, E, F , it isn't clear whether it should appear as abc FED or FED abc This kind of problem does not arise in CJK text. The orientation of CJK text is a presentation issue that is out of scope for Unicode. Peter Peter Constable Globalization Infrastructure and Font Technologies Microsoft Windows Division
RE: vertical direction control
[Original Message] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Date: 3/24/2004 2:35:50 PM Subject: RE: vertical direction control Which scripts are written bottom to top in vertical layout? The Unicode bidi faq tells that ancient Numidian was written bottom to top, and the Egyptian hieroglyphics could go basically in any direction. Then again, it also says that developers shouldn't really worry overmuch about these. It also doesn't account for boustrephedon writing direction either. If Moon Code [1] is ever added as a Unicode script, then Unicode may need to deal with the fact that this script is written today using boustrephedon. The other boustrephedon scripts are, if I remember correctly, either ancient and/or also usable with a non-boustrephedon writing direction. On the other hand, it might just leave this detail to a higher level protocol. [1] http://www.bsblind.co.uk/full/moon/typeindx.htm
RE: vertical direction control
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Cline It also doesn't account for boustrephedon writing direction either. Again, this is a presentation issue that doesn't require any new control characters. There is absolutely no reason, for instance, why an app couldn't be created that lays out Greek text in boustrophedon using the existing Greek characters. Of course, boustrophedon layout isn't needed to ensure legibility of Greek text; if it was, though, the solution would be to say that correct implementations of the Greek block required boustrophedon layout in the app, and not addition of new control characters. Peter Peter Constable Globalization Infrastructure and Font Technologies Microsoft Windows Division
Re: vertical direction control
At 14:49 +0100 2004-03-24, Chris Jacobs wrote: It seems strangely inconsistent to me that Unicode has detailed controls for horizontal layout direction and the complex bidi algorithm, but has nothing for vertical layout. I can force Latin text to be rendered right to left or Hebrew left to right (although such overrides are hardly plain text issues), but there is no way I can select vertical layout even for languages in which that is a normal way of writing. We already have U+202A LEFT-TO-RIGHT EMBEDDING and U+202B RIGHT-TO-LEFT EMBEDDING. It would be easy to define new characters TOP-TO-BOTTOM EMBEDDING and BOTTOM-TO-TOP EMBEDDING, with similar scope until the next PDF character. Which scripts are written bottom to top in vertical layout? Ogham and sometimes Tifinagh. -- Michael Everson * * Everson Typography * * http://www.evertype.com
RE: vertical direction control
At 09:06 -0800 2004-03-24, Peter Constable wrote: Of course, boustrophedon layout isn't needed to ensure legibility of Greek text; if it was, though, the solution would be to say that correct implementations of the Greek block required boustrophedon layout in the app, and not addition of new control characters. You say this as though creating an app were something that anyone could do. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: vertical direction control
From: Chris Jacobs [EMAIL PROTECTED] Which scripts are written bottom to top in vertical layout? Latin is quite often written in that direction, after rotating the letters too. See the many anotations or titles in books printed in the margin. OK this is not a property of the script, but a presentation feature that could be used by almost any script which have a strong writing direction.
Re: vertical direction control
On 24/03/2004 08:24, Peter Constable wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Peter Kirk It seems strangely inconsistent to me that Unicode has detailed controls for horizontal layout direction and the complex bidi algorithm, but has nothing for vertical layout. The bidi embedding and overrides are needed to maintain legibility of the text is certain situations. Orientation controls for CJK text are not needed to ensure legibility. For instance, given an encoded sequence a, b, c, space, D, E, F , it isn't clear whether it should appear as abc FED or FED abc This kind of problem does not arise in CJK text. The orientation of CJK text is a presentation issue that is out of scope for Unicode. Well, surely there is at least in principle an ambiguity between D abc E F and abc D E F -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: vertical direction control
On 24/03/2004 05:49, Chris Jacobs wrote: It seems strangely inconsistent to me that Unicode has detailed controls for horizontal layout direction and the complex bidi algorithm, but has nothing for vertical layout. I can force Latin text to be rendered right to left or Hebrew left to right (although such overrides are hardly plain text issues), but there is no way I can select vertical layout even for languages in which that is a normal way of writing. We already have U+202A LEFT-TO-RIGHT EMBEDDING and U+202B RIGHT-TO-LEFT EMBEDDING. It would be easy to define new characters TOP-TO-BOTTOM EMBEDDING and BOTTOM-TO-TOP EMBEDDING, with similar scope until the next PDF character. Which scripts are written bottom to top in vertical layout? If I remember well then both latin and hebrew script are written top to bottom. . I think we are talking at cross purposes here. You are talking about the direction of successive lines. I was thinking of the direction of characters. That is what I thought the original question was about, and it is certainly what most of the ongoing discussion has been about. I don't know of any scripts in which the ordering of lines is bottom to top. But in scripts in which the character direction is top to bottom the column direction may be right to left (e.g. Chinese) or left to right (e.g. Mongolian). -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: vertical direction control
At 10:30 -0800 2004-03-24, Peter Kirk wrote: I don't know of any scripts in which the ordering of lines is bottom to top. Orkhon (Old Turkic). -- Michael Everson * * Everson Typography * * http://www.evertype.com
RE: vertical direction control
[Original Message] From: Peter Constable [EMAIL PROTECTED] From: Ernest Cline It also doesn't account for boustrephedon writing direction either. Again, this is a presentation issue that doesn't require any new control characters. There is absolutely no reason, for instance, why an app couldn't be created that lays out Greek text in boustrophedon using the existing Greek characters. Of course, boustrophedon layout isn't needed to ensure legibility of Greek text; if it was, though, the solution would be to say that correct implementations of the Greek block required boustrophedon layout in the app, and not addition of new control characters. For the scripts that are currently in Unicode, I agree. However, for a boustrophedon only script such as Moon Code, it will prove needful to handle this in some manner, if for no other reason than to determine how it would fit into the bidirectional algorithm. It might be sufficient to give such scripts their own Bidirectional Character Type. (For instance, LB Left-to-Right Boustrophedon for a boustrophedon script that normally starts with its first line going left-to-right, as is the case for Moon Code. If needed, type RB could also be added, altho I am unaware of any boustrophedon only script that prefers to start going right-to-left.) It is reasonable for Unicode to ignore boustrophedon at present because it is not necessary for the scripts it currently supports and it adds an extra and usually unneeded layer of complexity to the bidirectional algorithm. If Unicode ever adds a boustrophedon only script, then in my opinion, leaving the issue to higher levels would be insufficient and Unicode will have to bite the bullet and address boustrophedon in the standard itself.
RE: vertical direction control
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Everson Of course, boustrophedon layout isn't needed to ensure legibility of Greek text; if it was, though, the solution would be to say that correct implementations of the Greek block required boustrophedon layout in the app, and not addition of new control characters. You say this as though creating an app were something that anyone could do. Not at all. I'm just saying what's the right way to deal with it as far as Unicode and implementations of Unicode are concerned. Peter Peter Constable Globalization Infrastructure and Font Technologies Microsoft Windows Division
RE: vertical direction control
From: Ernest Cline [mailto:[EMAIL PROTECTED] However, for a boustrophedon only script such as Moon Code, it will prove needful to handle this in some manner, if for no other reason than to determine how it would fit into the bidirectional algorithm. Sure, the interaction of a boustrophedon with bidi is a valid issue. Peter Constable
RE: vertical direction control
From: Peter Kirk [mailto:[EMAIL PROTECTED] Well, surely there is at least in principle an ambiguity between D abc E F and abc D E F Both are legible and have the same meaning. The issue of choice of presentation is out of scope for Unicode. Peter Peter Constable Globalization Infrastructure and Font Technologies Microsoft Windows Division
Re: vertical direction control
On Wed, 24 Mar 2004 14:09:11 +, Michael Everson [EMAIL PROTECTED] said: At 14:49 +0100 2004-03-24, Chris Jacobs wrote: It seems strangely inconsistent to me that Unicode has detailed controls for horizontal layout direction and the complex bidi algorithm, but has nothing for vertical layout. I can force Latin text to be rendered right to left or Hebrew left to right (although such overrides are hardly plain text issues), but there is no way I can select vertical layout even for languages in which that is a normal way of writing. We already have U+202A LEFT-TO-RIGHT EMBEDDING and U+202B RIGHT-TO-LEFT EMBEDDING. It would be easy to define new characters TOP-TO-BOTTOM EMBEDDING and BOTTOM-TO-TOP EMBEDDING, with similar scope until the next PDF character. Which scripts are written bottom to top in vertical layout? Ogham and sometimes Tifinagh. worthless trivia Also Numidian (if you count it seperate from Tifinagh), and various scripts from the Philippines: Tagalog (and its relatives) and Mangyan. The surviving Mangyan users seem to write it left to right when using paper, though. end of worthless trivia -- Benjamin Peterson [EMAIL PROTECTED]
Re: vertical direction control
At 11:33 -0800 2004-03-24, Benjamin Peterson wrote: Also Numidian (if you count it seperate from Tifinagh), I don't, not at this stage anyway. and various scripts from the Philippines: Tagalog (and its relatives) and Mangyan. The surviving Mangyan users seem to write it left to right when using paper, though. Even when they are written from the body outward (when carving etc.), they are not read that way, so I wouldn't count that as a bottom-to-top script. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: vertical direction control
I think we are talking at cross purposes here. You are talking about the direction of successive lines. No, I am not. I mean latin and hebrew in vertical layout, this happens if it is mixed with han in vertical layout. Latin is then rotated 90 degrees clockwise, changeing it from top to bottom. Hebrew is then rotated 90 degrees counterclockwise, changeing it also from top to bottom. See the 4.0 unicode book page 42,43
Re: vertical direction control
[Original Message] From: Benjamin Peterson [EMAIL PROTECTED] On Wed, 24 Mar 2004 14:09:11 +, Michael Everson [EMAIL PROTECTED] said: At 14:49 +0100 2004-03-24, Chris Jacobs wrote: Which scripts are written bottom to top in vertical layout? Ogham and sometimes Tifinagh. worthless trivia Also Numidian (if you count it separate from Tifinagh), and various scripts from the Philippines: Tagalog (and its relatives) and Mangyan. The surviving Mangyan users seem to write it left to right when using paper, though. end of worthless trivia Actually, from what sources I've seen, while the Philippine scripts were sometimes written as if they were bottom to top when using materials other than paper, it was always read left to right. It was a case of it being more convenient with the materials used to write it bottom to top, but it was never intended to be read that way.
Re: vertical direction control
At 15:10 -0500 2004-03-24, Ernest Cline wrote: Actually, from what sources I've seen, while the Philippine scripts were sometimes written as if they were bottom to top when using materials other than paper, it was always read left to right. It was a case of it being more convenient with the materials used to write it bottom to top, but it was never intended to be read that way. As I said, it was written from-the-body-out. -- Michael Everson * * Everson Typography * * http://www.evertype.com
RE: vertical direction control
Ernest Cline wrote: It also doesn't account for boustrephedon writing direction either. ^ boustrophedon Gr. strepho, but pf. estropha Intentionally. That is an issue for a higher-level protocol concerned with line layout, rather than the plain text encoding itself. By the way, while Peter Constable noted that the interaction of a boustrophedon with bidi is a valid issue. I would contend that that is at the higher level where bidi interacts with the line layout mechanism that determines the directional context, rather than inside the bidi algorithm itself. Besides, this is really a very, very marginal concern. All real world exemplars of boustrophedon are *not* bidirectional text, and all real world exemplars of bidirectional text are not laid out in boustrophedon. Why? Well, because it would be a stupid thing to do and give readers and writers headaches. If Moon Code [1] is ever added as a Unicode script, then Unicode may need to deal with the fact that this script is written today using boustrephedon. The other boustrephedon scripts are, if I remember correctly, either ancient and/or also usable with a non-boustrephedon writing direction. On the other hand, it might just leave this detail to a higher level protocol. Exactly. Tinkering with the bidi algorithm to try deal with boustrophedon is just silly. [1] http://www.bsblind.co.uk/full/moon/typeindx.htm Is Moon Type in actual use, or just a historical curiosity? William Moon was a 19th century figure. Some things to note: Moon Type is a Left-to-right script, just like Greek, that happens to be laid out in boustrophedon to assist in fingers following the lines of type from one side of the page to the other. Very reasonable experiment for an embossed writing system for the blind. In its intended use, for embossed writing for the blind, Moon Type could not be mixed with anything else. But, of course, metatexts *about* Moon Type, like that website, can and do mix such symbols with Latin text. However, there is no indication that a bi-script Latin/Moon text per se would make any sense. The main alphabet is an Latin cipher -- one character for each of the 26 letters A-Z. But there are additional symbols for some common English phonemes and some abbreviatory conventions, a numeric sign, and so forth, that would require additional characters to encode such a system. It is an English-only system, by the way, with lists of word abbreviations for common English words. --Ken
Re: vertical direction control
Chris Jacobs wrote: I mean latin and hebrew in vertical layout, this happens if it is mixed with han in vertical layout. Latin is then rotated 90 degrees clockwise, changeing it from top to bottom. Hebrew is then rotated 90 degrees counterclockwise, changeing it also from top to bottom. Not always true: sometimes numbers will appear like this: XX (wheras represents CJK characters and XX represents a number) The number is in this case not rotated at all. Stefan
RE: vertical direction control
At 13:55 -0500 2004-03-24, Ernest Cline wrote: It is reasonable for Unicode to ignore boustrophedon at present because it is not necessary for the scripts it currently supports and it adds an extra and usually unneeded layer of complexity to the bidirectional algorithm. If Unicode ever adds a boustrophedon only script, then in my opinion, leaving the issue to higher levels would be insufficient and Unicode will have to bite the bullet and address boustrophedon in the standard itself. Perhaps you should take this up with the keepers of the Bidi algorithm, Ernest. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: vertical direction control
On 24/03/2004 12:10, Ernest Cline wrote: ... Actually, from what sources I've seen, while the Philippine scripts were sometimes written as if they were bottom to top when using materials other than paper, it was always read left to right. It was a case of it being more convenient with the materials used to write it bottom to top, but it was never intended to be read that way. Some people write Latin script more or less bottom to top with lines left to right. But it is not normally read like that, unless perhaps you are reading over someone else's shoulder. Direction of handwriting is hardly relevant to Unicode as Unicode rendering is not actual handwriting. What is relevant is the normal expected direction of reading. -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: vertical direction control
On 24/03/2004 11:53, Chris Jacobs wrote: I think we are talking at cross purposes here. You are talking about the direction of successive lines. No, I am not. I mean latin and hebrew in vertical layout, this happens if it is mixed with han in vertical layout. Latin is then rotated 90 degrees clockwise, changeing it from top to bottom. Hebrew is then rotated 90 degrees counterclockwise, changeing it also from top to bottom. See the 4.0 unicode book page 42,43 I have an example of Chinese set as RTL in a line mixed with Arabic script, in what looks like a dictionary from an Arabic script language to Chinese. -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: vertical direction control
Am 2004-03-23 21:57 schrieb Ernest Cline: I suppose one could use the ECMA-48 / ISO 6429 SPD (Select Presentation Direction) control sequence, but that is hardly plain text, altho it isn't quite markup either. After having a glimpse on ECMA-48(Control Functions for Coded Character Sets) I am not sure how this concept would interact with the bidi algorithm - especially if glyphs should be mirrored, rotated or simply reordered. Thomas Kuehne
Re: vertical direction control
On 24/03/2004 12:31, Kenneth Whistler wrote: [1] http://www.bsblind.co.uk/full/moon/typeindx.htm Is Moon Type in actual use, or just a historical curiosity? William Moon was a 19th century figure. The last section of Moon, Matches and Microchips, accessible from http://www.bsblind.co.uk/full/moon/index.htm, implies that Moon script was in use in 1988. The following, from the recently updated http://www.rnib.org.uk/xpedio/groups/public/documents/publicwebsite/public_factlist.hcsp, suggests that it is still in use: RNIB can help you put your information into the format you require. A number of factsheets on braille, Moon, large print and other media are available free of charge from RNIB Customer Services, PO Box 173, Peterborough, PE2 6WS, telephone 0845 702 3153. See also http://www.rnib.org.uk/xpedio/groups/public/documents/publicwebsite/public_aboutbm.hcsp. And there is a long (and recent) discussion about whether Moon might be more suitable than Braille in http://www.rnib.org.uk/xpedio/groups/public/documents/publicwebsite/public_rnib003514.doc, section 4.7.1. So Moon is not just a historical curiosity. The only reason for it not being suitable for Unicode, and the BMP, is the argument that it is a cipher of Latin. But it has different layout characteristics as well as its abbreviations and contractions. And surely Braille could equally be considered a cipher of Latin script (although the same symbols are also used as a cipher of other scripts). -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
RE: vertical direction control
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Whistler By the way, while Peter Constable noted that the interaction of a boustrophedon with bidi is a valid issue. I would contend that that is at the higher level where bidi interacts with the line layout mechanism that determines the directional context, rather than inside the bidi algorithm itself... I was simply suggesting that there may be issues there to consider, but not necessarily implying that the bidi algorithm needed to address in any way interactions between boustrophedon and non-boustrophedon text. I *could not possibly* suggest that until I had some idea of what the expected behaviour should be. I'm not aware of there being any conventionally-defined behaviour for interaction between strong LTR or RTL text and boustrophedon text. The requirements have to be defined before a solution can be architected. And as you go on to point out... Besides, this is really a very, very marginal concern. All real world exemplars of boustrophedon are *not* bidirectional text, and all real world exemplars of bidirectional text are not laid out in boustrophedon. Why? Well, because it would be a stupid thing to do and give readers and writers headaches. it's not obvious that requirements do exist. Peter Peter Constable Globalization Infrastructure and Font Technologies Microsoft Windows Division
Re: vertical direction control
Am 2004-03-23 20:23 schrieb Asmus Freytag: I don't think I know of a scenario where it is crtical for a resource limited device to display the kinds of texts you list below. Reading the font data and processing it into a display representation poses the same resource costs for mirrored, rotated and normal glyphs. The limitations are mainly processing speed and memory/storage. On the display side there are few potential problems. Thomas Kuehne
RE: vertical direction control
[Original Message] From: Kenneth Whistler [EMAIL PROTECTED] Is Moon Type in actual use, or just a historical curiosity? William Moon was a 19th century figure. Yes, it is still in use, altho mainly in the UK. It is reportedly easier for those who have lost their sight to learn Moon Code than Braille, and also there also some who were born blind and with learning handicaps as well who are able to use Moon Code but not Braille. In its intended use, for embossed writing for the blind, Moon Type could not be mixed with anything else. But, of course, metatexts *about* Moon Type, like that website, can and do mix such symbols with Latin text. However, there is no indication that a bi-script Latin/Moon text per se would make any sense. For those who are newly blind, Moon Code is sometimes used as a stepping stone to Braille, which would make Moon Code / Latin Braille texts a possibility in my opinion. The main alphabet is an Latin cipher -- one character for each of the 26 letters A-Z. But there are additional symbols for some common English phonemes and some abbreviatory conventions, a numeric sign, and so forth, that would require additional characters to encode such a system. It is an English-only system, by the way, with lists of word abbreviations for common English words. True. If one ignores the boustrophedon nature of Moon Code then it would suffice to add just a few extra characters. The CH, TH and WH glyphs in this case could be adequately represented with use of COMBINING SMALL LETTER H (U+036A) so that would leave the abbreviation symbol, the verse separator and maybe the guide lines to be encoded.
Re: vertical direction control
Peter Kirk recently said: It seems strangely inconsistent to me that Unicode has detailed controls for horizontal layout direction and the complex bidi algorithm, but has nothing for vertical layout. I can force Latin text to be rendered right to left or Hebrew left to right (although such overrides are hardly plain text issues), but there is no way I can select vertical layout even for languages in which that is a normal way of writing. We already have U+202A LEFT-TO-RIGHT EMBEDDING and U+202B RIGHT-TO-LEFT EMBEDDING. It would be easy to define new characters TOP-TO-BOTTOM EMBEDDING and BOTTOM-TO-TOP EMBEDDING, with similar scope until the next PDF character. The difficult part would be implementing this, and before that defining the exact semantics (but Unicode could define the semantics as beyond its scope). (Another problem would be deciding which variant of mirrored characters e.g. brackets to use given that the context is neither RTL nor LTR - this is a problem with Egyptian hieroglyphs, many of which are mirrored in horizontal text.) For Egyptian hieroglyphs the characters generally face towards the start of the reading direction. (The occasional one is reversed, and sometimes whole texts face the wrong way.) So for horizontal l-to-r t-to-b face left, r-to-l t-to-b face right. For vertical t-to-b l-to-r face left, t-to-b r-to-l face right. In this case the fact the the inscription is top to bottom doesn't help - you need to know what the column arrangement is. You can even have both arrangements in one inscription, e.g. on either side of a doorway the figures face towards the door. (The bit over the door had the same arrangement as one of the sides rather than meeting halfway in the example I've seen.) IIRC it's like RLL R L R L Captions next to people in a larger picture usually face in the same direction as the person. Tim -- Tim Partridge. Any opinions expressed are mine only and not those of my employer
Re: vertical direction control
Kenneth Whistler scripsit: Ernest Cline wrote: It also doesn't account for boustrephedon writing direction either. ^ boustrophedon Ah well. I once referred to Herodotos throughout a posting as Herotodos (googling for it gets 17 hits, the first two of which are mine (blush)). Not surprising when you pronounce it [EMAIL PROTECTED][EMAIL PROTECTED]@s], as I do. ( = primary stress, 4 = fishhook r, 3\ = rhotacized reverse epsilon, A = alpha). -- John Cowan [EMAIL PROTECTED] www.ccil.org/~cowan www.reutershealth.com If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton
Re: vertical direction control
Regarding Moon script... and Braille... And surely Braille could equally be considered a cipher of Latin script (although the same symbols are also used as a cipher of other scripts). No, Braille is not a cipher of any other script. It is *not* simply one-to-one mappable to/from the Latin script. There are ambiguous constructs that cannot be back-mapped uniquely. It is in fact a separate script. Regarding Moon, my informant last said in 2002: This is a raised script used by a small user community in Great Britain. He further said, computerized Moon is always read from left to right. Again, The Royal National Institute for the blind is the last producer of Moon texts and it is widely read by older blind persons in England. Nobody has made any proposal for encoding it. It is English only; and it is a cipher of Latin, except for a few symbols for word abbreviations, which certainlly *could* be encoded if someone wanted to take the trouble to propose them. A Unicode implementation would then use higher level protocol -- a font shift into Moon font using A-Z, with special symbols for the abbreviations. Rick
Re: vertical direction control
Regarding the use of higher level protocols to deal with the complex issues of vertical layout, the CSS 3 text module may be of interest: http://www.w3.org/TR/css3-text/ I believe CSS 2 includes writing-mode top-to-bottom right-to-left, but last I checked only Win IE 6 could do it.
Re: vertical direction control
On 24/03/2004 14:07, [EMAIL PROTECTED] wrote: Kenneth Whistler scripsit: Ernest Cline wrote: It also doesn't account for boustrephedon writing direction either. ^ boustrophedon Ah well. I once referred to Herodotos throughout a posting as Herotodos (googling for it gets 17 hits, the first two of which are mine (blush)). Not surprising when you pronounce it [EMAIL PROTECTED][EMAIL PROTECTED]@s], as I do. ( = primary stress, 4 = fishhook r, 3\ = rhotacized reverse epsilon, A = alpha). Herotodos - 17 hits Herodotos - 8,730 hits Herotodus - 528 hits Herodotus - 165,000 hits Obviously the Latinised version, with -us instead of the original Greek -os, is much the most widely used. -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: vertical direction control
At 02:58 PM 3/24/2004, Thomas Kuehne wrote: Am 2004-03-23 20:23 schrieb Asmus Freytag: I don't think I know of a scenario where it is crtical for a resource limited device to display the kinds of texts you list below. Reading the font data and processing it into a display representation poses the same resource costs for mirrored, rotated and normal glyphs. The limitations are mainly processing speed and memory/storage. On the display side there are few potential problems. Unless you eventually display text, you don't need to deal with direction control. That's why I used the term 'display' in posing my question earlier. Let me rephrase it: I don't think I know of a scenario where it is critical for a resource limited device to support the selection of vertical vs. non-vertical display of text. Unless there is some such scenario, there's no need to even speculate about alternatives to existing markup languages. I have not seen a credible scenario. Bidirectional controls are different: Even on the most limited device displaying text, for example for text messages on a cell phone, you need to run the bidirectional algorithm for bidi scripts. As the algorithm uses heuristics, some form of additional controls are needed to disambiguate certain cases. Many 8-bit sets support only a subset of these, i.e. RLM/LRM, but not the additional set of stateful controls. See for example UTR#20 (http://www.unicode.org/reports/tr20/) why having control codes for these purposes can cause issues in migrating text between plain text and marked-up text. A./
Re: vertical direction control
On 24/03/2004 12:31, Kenneth Whistler wrote: ... Besides, this is really a very, very marginal concern. All real world exemplars of boustrophedon are *not* bidirectional text, and all real world exemplars of bidirectional text are not laid out in boustrophedon. Why? Well, because it would be a stupid thing to do and give readers and writers headaches. I wonder if there are in fact any cases where fixed direction text is embedded in boustrophedon. For example, when numbers or foreign loan words are written in boustrophedon texts, do they have fixed LTR or RTL directionality? I don't think that would necessarily be stupid, and just because it seems stupid to us that doesn't mean it doesn't happen. (There are many things in non-western scripts which seem stupid to me, and there are doubtless many things in Latin script which seem stupid to non-westerners.) If this does happen, there may need to be ways to indicate this - that is, if in future any boustrophedon text is defined in Unicode. Indeed, whether or not it happens someone needs to define the expected appearance of small groups of non-boustprohedon characters appearing in a boustrophedon text, even if vice versa is less of a problem. -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: vertical direction control
Herotodos - 17 hits Herodotos - 8,730 hits Herotodus - 528 hits Herodotus - 165,000 hits And don't forget: Herodatus - 168 hits Heradotus - 14 hits Heradatus - 7 hits Herotadus - 1 hit Which I guess only further demonstrates how worthless English orthography is after the Great Vowel Shift, unstressed vowel reductions, and intervocalic neutralization of t/d. Any well you spell it -- left to right or top to bottom or both ways from Sunday, English spelling doesn't make any sense. It ought to be spelled: HuhRODuhduhs :-) --Ken
Re: vertical direction control
Tom Gewecke wrote: I believe CSS 2 includes writing-mode top-to-bottom right-to-left, but last I checked only Win IE 6 could do it. Last time I checked, Win IE 6 took notice of the CSS markup and displayed the text wrong, while all other web browsers ignored the CSS. Stefan
Re: vertical direction control
Peter Kirk peterkirk at qaya dot org wrote: And surely Braille could equally be considered a cipher of Latin script (although the same symbols are also used as a cipher of other scripts). ... which is one reason it can't be considered just a cipher of Latin. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
Re: vertical direction control
Kenneth Whistler scripsit: It ought to be spelled: HuhRODuhduhs But those d's aren't diaphonematic. My correspondent's a Brit, and he spotted the error immediately, because of course there's no neutralization for him. Axel Wijk rulez. -- John Cowan [EMAIL PROTECTED] http://www.ccil.org/~cowan Raffiniert ist der Herrgott, aber boshaft ist er nicht. --Albert Einstein
Re: vertical direction control
[Original Message] From: John Cowan [EMAIL PROTECTED] Kenneth Whistler scripsit: It ought to be spelled: HuhRODuhduhs But those d's aren't diaphonematic. My correspondent's a Brit, and he spotted the error immediately, because of course there's no neutralization for him. And dhat's wot stans in dhee way uv spelling reeform. Inglish haz too menee dielects too enaybul enee singul won uv dhem too bee youzd az u baysis for u reeform dhat wood bee akseptuble too awl uv dhe udherz. Awlsoe, nun uv dhem iz powerful eenuf too bee forst upun dhee udherz. If insted uv Inglish, wee had British, Umerikan, Awstrailyun, et seteru, it miet bee possibul too establish foenetik spelling for eech uv dhe noo langwajes, but I dowt if dhat wil happen enee tiem soon, if at awl.
Re: vertical direction control
Ernest Cline scripsit: And dhat's wot stans in dhee way uv spelling reeform. No, Regularized Inglish is perfectly practical, which is why I sed that Axel Wijk rules. Keep a few pronunciations ov each sound and regularize away the rest, and yoo get a sensible spelling reform. -- John Cowan [EMAIL PROTECTED] http://www.reutershealth.com I amar prestar aen, han mathon ne nen,http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, LOTR:FOTR
Re: vertical direction control
At 02:55 PM 3/23/2004, Thomas Kuehne wrote: Is somebody already using a PUA assignment for vertical text direction controls? from http://www.unicode.org/faq/bidi.html#1 [...] the choice of vertical layout is usually treated as a formatting style; therefore, the Unicode Standard does not define default rendering behavior for vertical text nor provide directionality controls designed to override such behavior. Thanks in advance for any hints, I think the idea was that these don't belong in plain text. Markup languages have had vertical layout controls forever. A./
Re: vertical direction control
Am Mittwoch 24 März 2004 00:09 schrieb Asmus Freytag: Is somebody already using a PUA assignment for vertical text direction controls? I think the idea was that these don't belong in plain text. Markup languages have had vertical layout controls forever. The problem arose at very resource limited devices, thus no HTML nor RTF etc.. In fact there is no higher level protocol other than plain strings/text. While crawling through the Pango and SilGraphite rendering engines I noticed that they provide(or are planning to) an interface for vertical text. For CJK, old European in-scripts and especially Egyptian hieroglyphs it would be good to have a common control set - otherwise plain text can't be used for data exchange. Thomas Kuehne
RE: vertical direction control
Title: RE: vertical direction control From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Kuehne Sent: Tuesday, March 23, 2004 6:09 PM For CJK, old European in-scripts and especially Egyptian hieroglyphs it would be good to have a common control set - otherwise plain text can't be used for data exchange. Do you have examples of cases where vertical control has content? I thought there were no such cases known. /|/|ike
Re: vertical direction control
At 06:09 PM 3/23/2004, Thomas Kuehne wrote: Am Mittwoch 24 März 2004 00:09 schrieb Asmus Freytag: Is somebody already using a PUA assignment for vertical text direction controls? I think the idea was that these don't belong in plain text. Markup languages have had vertical layout controls forever. The problem arose at very resource limited devices, thus no HTML nor RTF etc.. In fact there is no higher level protocol other than plain strings/text. I don't think I know of a scenario where it is crtical for a resource limited device to display the kinds of texts you list below. For CJK, use of horizontal text is common for resource limited devices such as LED or small LCD panel displays, or, for that matter, most computer interfaces (as opposed to formatted documents on a computer). While crawling through the Pango and SilGraphite rendering engines I noticed that they provide(or are planning to) an interface for vertical text. For CJK, old European in-scripts and especially Egyptian hieroglyphs it would be good to have a common control set - otherwise plain text can't be used for data exchange. Thomas Kuehne A./
Re: vertical direction control
I can't imagine a situation where this would matter for plain text. I suppose one could use the ECMA-48 / ISO 6429 SPD (Select Presentation Direction) control sequence, but that is hardly plain text, altho it isn't quite markup either.
