Hebrew

Hebrew

[Robert C. Leif, Ph.D.]

From: Bob Leif
I went to the World Wide Web Consortium Web site and looked up Hebrew and
found this URL:
--------------------------------
http://www.w3.org/TR/1999/WD-SVG-19991203/fonts.html
(Section)20 Fonts

Contents
20.1 Introduction
20.2 SVG fonts
20.2.1 Overview of SVG fonts
20.2.2 The 'font' element
20.2.3 The 'glyph' element
20.2.4 The 'missing-glyph' element
20.2.5 The 'hkern' and 'vkern' elements
20.3 DOM interfaces
20.3.1 Interface SVGFontElement
20.3.2 Interface SVGGlyphBaseElement
20.3.3 Interface SVGGlyphElement
20.3.4 Interface SVGMissingGlyphElement
20.3.5 Interface SVGKernBaseElement
20.3.6 Interface SVGHKernElement
20.3.7 Interface SVGVKernElement

horiz-adv-x = "<number>"
The horizontal advance after rendering a glyph in horizontal orientation.
The default value is the value of the font's horizAdvX attribute. Glyph
widths are required to be positive, even if the glyph is typically rendered
right-to-left, as in Hebrew and Arabic scripts.
------------------------------------------------
I would like to see this type of functionality in Ada. However as a
practical matter, the use of web technology to display Hebrew can be as
above or as the Israelis are doing it.

Re: Hebrew

[David Starner]

On Sat, 7 Apr 2001 22:33:29 -0700, Robert C. Leif, Ph.D. <rleif@rleif.com> wrote:
> The horizontal advance after rendering a glyph in horizontal orientation.
> The default value is the value of the font's horizAdvX attribute. Glyph
> widths are required to be positive, even if the glyph is typically rendered
> right-to-left, as in Hebrew and Arabic scripts.
> ------------------------------------------------
> I would like to see this type of functionality in Ada. However as a
> practical matter, the use of web technology to display Hebrew can be as
> above or as the Israelis are doing it.

What type of functionality? Right-to-left? It doesn't seem like that 
big a deal - wide_text_io could handle it right now, right? Personally,
I'd find normalization functions to be more useful; rtl only matters
when dumping to a terminal without higher-order protocols (curses 
should handle it for you, if and when anyone does serious work on 
UTF-8 compatibility), whereas normalization comes in handy when ever
you run into Unicode text from the outside.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Hebrew

[Florian Weimer]

"Robert C. Leif, Ph.D." <rleif@rleif.com> writes:

> horiz-adv-x = "<number>"
> The horizontal advance after rendering a glyph in horizontal orientation.
> The default value is the value of the font's horizAdvX attribute. Glyph
> widths are required to be positive, even if the glyph is typically rendered
> right-to-left, as in Hebrew and Arabic scripts.

> I would like to see this type of functionality in Ada.

Why?  This seems to have an application only in the highly specialized
field of GUI, doesn't it?

Re: Hebrew

[Florian Weimer]

dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) writes:

> What type of functionality? Right-to-left? It doesn't seem like that 
> big a deal - wide_text_io could handle it right now, right?

In the Unicode universe, handling right-to-left scripts correctly is
mostly the job of the terminal, not of the application.  Unicode
stores characters in logical order, not in visual order.

Re: Hebrew

[Mike Brenner]

>> What type of functionality? Right-to-left? It doesn't seem like that big a deal - wide_text_io could handle it right now, right?

Florian Weimer wrote:
> In the Unicode universe, handling right-to-left scripts correctly is mostly the job of the terminal, not of the application. Unicode stores characters in logical order, not in visual order.


To expand on that, the renderer (terminal driver, print
driver, etc.) is the component that goes back and forth, but
some systems have directional attributes that tell the
device driver when to go back and forth. See, for example,
http://www.htmlhelp.com/reference/html40/attrs.html which
shows how this is done for web pages using html 4.0 using
the dir=rtl (direction=right2left) attribute.

The point is that Ada would just be generating the string
and the device driver would be interpreting the string; that
is, the device driver would be making it switch to
right2left mode, not Ada.

BTW this is important for quite a few languages, not just
Hebrew. It is fundamental for Arabic, Biblical Hebrew,
Farsi, Ancient Greek, etc., per se. But many languages, like
English, Hindi, Chinese, Japanese, etc., also use different
directions of text when quoting right-to-left languages in
the middle of left-to-right text, or when writing in columns
or other than left-to-right paragraphs.

-----

This is like the question of whether coding should be done
in UTF-8 or use a 16-bit character encoding. UTF-8 has
advantages for websites in simple English and most American
emails. Various 16-bit codes have advantages for Asian
languages, eCommerce encodings, multi-language web sites.
The question is, is it important for English speaking people
to make codings, software, web sites, advertisements, etc.,
that work well for people of many different languages?

Or, to restate that question, is it important for Asia to
use the same Unicode, the same character encodings, and
ultimately, compatible web pages with Europe and the
Americas?

It is amazing that in 2001 the fonts that come with American
computers and web browsers don't include most of Unicode
yet.

Mike

Re: Hebrew

[David Starner]

On Mon, 09 Apr 2001 10:24:08 -0400, Mike Brenner <mikeb@mitre.org> wrote:
> This is like the question of whether coding should be done
> in UTF-8 or use a 16-bit character encoding. 
[...]
> Or, to restate that question, is it important for Asia to
> use the same Unicode, the same character encodings, and
> ultimately, compatible web pages with Europe and the
> Americas?

You mean UTF-16? UTF-8's not the only encoding for Unicode.  There's
no problem using UTF-16 in areas that don't need to be
ASCII-compatible. It's trivial to convert UTF-16 to UTF-8 with no
loss of information or vice versa. 

> It is amazing that in 2001 the fonts that come with American
> computers and web browsers don't include most of Unicode
> yet.

On one hand, it's not surprising at all; is it commericially 
reasonable for Microsoft to spend a lot of time for Cherokee,
or the UCAS or polytonic Greek? How important is it that the
average person, who knows no Japenese, has Japenese display
correctly? On the other hand, they do - Windows comes with a 
nice set of fonts that each cover all the basic Latin, Greek
and Cyrillic characters and provide full Unicode fonts for
download from their website for free. Recent versions of Linux
provide fairly complete Unicode BDF fonts. 

This is really starting to head off topic. I'll try to make
this my last post on the subject.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Hebrew

[Florian Weimer]

Mike Brenner <mikeb@mitre.org> writes:

> BTW this is important for quite a few languages, not just
> Hebrew. It is fundamental for Arabic, Biblical Hebrew,
> Farsi, Ancient Greek, etc., per se.

I believe that some languages (very Ancient Greek) use both writing
directions alternatively. There isn't much software which supports
that, if any at all.

> This is like the question of whether coding should be done
> in UTF-8 or use a 16-bit character encoding. UTF-8 has
> advantages for websites in simple English and most American
> emails.

The robustness and statelessness of UTF-8 is helpful if you're using a
Unicode-aware terminal in the UNIX environment.

> Various 16-bit codes have advantages for Asian
> languages, eCommerce encodings, multi-language web sites.

There are many, manu national standards, and I think that's a problem.
For a developer who is interested in internationalizing his software,
it's very difficult to obtain all the necessary documentation.
Implementing Unicode is probably much easier.

> The question is, is it important for English speaking people to make
> codings, software, web sites, advertisements, etc., that work well
> for people of many different languages?

Well, my native language is German, so my answer is yes, definitely.
(However, I'm not sure about web sites and advertisements.  Software,
howver, should be able to cope with text in a multitude of languages,
if it deals with text in any way at all.)

> Or, to restate that question, is it important for Asia to use the
> same Unicode, the same character encodings, and ultimately,
> compatible web pages with Europe and the Americas?

I think so.  At the university, I think many students would be glad if
they could use computers to read and write in their native language.
We can't install software versions for 100+ languages, so it's
important that existing software is internationalized.

> It is amazing that in 2001 the fonts that come with American
> computers and web browsers don't include most of Unicode yet.

This might change quickly as Microsoft is rapidly embracing Unicode
and is even implementing proper input methods, joining behavior etc.

Re: Hebrew

[Brian Rogoff]

On 9 Apr 2001, Florian Weimer wrote:
> Mike Brenner <mikeb@mitre.org> writes:
> 
> > BTW this is important for quite a few languages, not just
> > Hebrew. It is fundamental for Arabic, Biblical Hebrew,
> > Farsi, Ancient Greek, etc., per se.
> 
> I believe that some languages (very Ancient Greek) use both writing
> directions alternatively. There isn't much software which supports
> that, if any at all.

Word for the day: "boustrophedon". 

> > Various 16-bit codes have advantages for Asian
> > languages, eCommerce encodings, multi-language web sites.
> 
> There are many, manu national standards, and I think that's a problem.
> For a developer who is interested in internationalizing his software,
> it's very difficult to obtain all the necessary documentation.
> Implementing Unicode is probably much easier.
> 
> > The question is, is it important for English speaking people to make
> > codings, software, web sites, advertisements, etc., that work well
> > for people of many different languages?
> 
> Well, my native language is German, so my answer is yes, definitely.

My native language is American English, and I agree with you. However, 
I suspect that for the kinds of SW I work on, mostly engineering SW, 
the answer today is no. Still, a general purpose language should provide
the tools to implement internationalized software. 

-- Brian