Re: HTML Hebrew

On Sat, 19 May 2006, Stefano MAC:GREGOR wrote:

Andreas Prilop wrote:

Actually this problem has nothing to do with HTML. It is about the
placement of Hebrew vowel signs (here: holam). You should see it
in text/plain, too, or in any word processor.

Correct: the problem is the way that some browsers (at the very
least, IE) render the properly-coded HTML.

As I said, I'm not familiar with the script myself, although I am
interested in the web "technology"... After I *think* I understood
what you were explaining about what ought to happen, I tried some
variations with different (unicode-compatible) fonts that were
featuring Hebrew. Not only with MSIE, but also with web browsers such
as Mozilla/Seamonkey and Opera. All of them displayed your sample
with the "holam" as a character standing by itself, to the left of
your "lamed", showing no special treatment of the kind which you were
hoping for.

I found a kludge to get it to look the way I want, though. But of
cource, since it's a kludge, it's not really satisfying. Five of
the six fonts I have here which include the Hebrew letters have a
LAMED-holam ligature that looks exactly correct. The problem is
that it is "private use character", so it cannot be counted on.

Understood.

Moreover, to get it to render properly in the midst of other Hebrew
characters, the paragraph (or DIR, or whatever) must have a DIR=rtl
specified in the HTML.

That's curious. So it seems the rendering system does not know that
the character in question is an inherently rtl character. "Proper"
Unicode characters of course have their rtl property codified in the
Unicode specification. It had never occurred to me that there would
need to be some way for such properties to be defined for characters
in the PUA, but now that you mention it, it seems obvious. Maybe
someone knows how this would/should be done?

But, as Andreas P has often pointed out, and I say the same in my
pages, it is anyway good HTML practice when using rtl writing systems
to make liberal use of dir=rtl attributes to encourage rendering
systems to "do the right thing".

The actual solution will be to have Microsoft repair the browser.

Maybe; but seems to me that the problem extends to more than just one
MS browser-like application! Not only web browsers, but other text
rendering applications.

best regards.
.

Relevant Pages

  • Re: Text Edge Detection
    ... text with black halo around each character. ... I have a background image and some text written on top on it. ... This can usaually be done by rendering the text with transparent ... I am not sure if it would achieve the desired effect or not. ...
    (sci.image.processing)
  • Re: Text Edge Detection
    ... text with black halo around each character. ... I have a background image and some text written on top on it. ... This can usaually be done by rendering the text with transparent ... I am not sure if it would achieve the desired effect or not. ...
    (sci.image.processing)
  • Re: Generate a one-time pad from say a 256bit key?
    ... was arabic rathr than Hebrew (that being the most likely laptop to be found ... The question is whether or not that difference in Unicode character sets ... therer is still a large randomness in it and randomness in that ...
    (sci.crypt)
  • Re: Generate a one-time pad from say a 256bit key?
    ... The question is whether or not that difference in Unicode character sets ... between arabic and hebrew. ... that in English the 8th bit has zero entropy per bit. ...
    (sci.crypt)
  • Re: Entering Hebrew Text in Word 2004 for Mac
    ... AppleScripts for Entourage: ... I can enter this in using Apple’s keyboard viewer by selecting ... the Hebrew character set in Apple’s character palette. ... This rendering in Apple works in Entourage, ...
    (microsoft.public.mac.office.word)