Hebrew with diacritics: tests for web browsers
Aharon Varady
http://aharon.varady.net/browser-test-for-hebrew-diacritics.html
I made some changes for clarity of language and updated the results for the browsers I tested in Windows 7, GNU/Linux, and Android.
The good news is that most modern browsers are performing well.
The bad news is that I'm still seeing niqqud positioning errors on Android's browser and Firefox on Android. In my tests, Epiphany also is still having trouble positioning Hebrew with niqqud correctly.
I saw improvement with Lynx (CLI) and Links (the GUI version) which will now display Hebrew without having to make any settings changes. Unfortunately, Hebrew only displays LTR, rather than RTL. Links (CLI) will not do unicode Hebrew and although its GUI version will, it will display asterisks in place of niqqud.
It would be really great to have some javascript to report back on what the browser has set as the default character encoding. I've seen browsers set to other encodings display Hebrew correctly even when the code should be instructing the browser to use utf8. With some JS indicating to the user that their browser may not be setup correctly to view a website with Hebrew, users could be better informed.
In any case, please take what I've done here and if it inspires you, you are free to take the source and make improvements.
Aharon
Ze'ev Clementson
On Sun, Oct 30, 2011 at 9:34 AM, Aharon Varady <aharon...@gmail.com> wrote:
> Just updated the web browser tests for @font-face and Hebrew diacritic
> positioning.
>
> http://aharon.varady.net/browser-test-for-hebrew-diacritics.html
>
> I made some changes for clarity of language and updated the results for the
> browsers I tested in Windows 7, GNU/Linux, and Android.
>
> The good news is that most modern browsers are performing well.
In your browser results table, for Mac OS X 10.6.6 and Safari 5.0.,
you indicate n/a, FAIL, FAIL for the 3 test results and say that
@font-face skipped Miriam CLM. I tried the test page on:
Mac OS X 10.6.8 and Safari 5.0.5
and
Mac OS X 10.7.2 and Safari 5.1.1
and it looks (to me) like both are passing some of the tests now
(unless I misinterpreted what you're testing). The default system font
diacritic positioning is not always pretty (but you don't have a
column for that anyhow), but the Ezra SIL, Miriam CLM, and @font-face
tests seem to be ok. Attached are screenshots of the 3 tests (from Mac
OS X 10.7.2 and Safari 5.1.1). Should you update the table with these
results?
On iOS 5.0 on the iPhone, Safari produces LOUD diacritic errors for
Miriam CLM and Ezra SIL with @font-face (this is probable @font-face
related because I can display those fonts in a UIWebview without
problems) but the system font diacritic placement is much better than
on the Mac version of Safari.
Ze'ev
Aharon Varady
In your browser results table, for Mac OS X 10.6.6 and Safari 5.0.,
you indicate n/a, FAIL, FAIL for the 3 test results and say that
@font-face skipped Miriam CLM. I tried the test page on:
Mac OS X 10.6.8 and Safari 5.0.5
and
Mac OS X 10.7.2 and Safari 5.1.1
Good to hear that Safari on Macs are rendering Hebrew fonts with @font-face, and doing so as well as other modern browsers on their platforms.
On iOS 5.0 on the iPhone, Safari produces LOUD diacritic errors for
Miriam CLM and Ezra SIL with @font-face
That's interesting that iOS produced errors for Ezra SIL SR. @font-face is working but the positioning is off and it's producing an error. The Android browsers also have problems with diacritic positioning with Ezra but they fail quietly.
To pass @font-face, all I expect is that the font is rendered. I think it's up to the browser to render the positioning in all fonts correctly, so long as the positioning logic is correct in the font itself.
Should you update the table with these results?
http://aharon.varady.net/browser-test-for-hebrew-diacritics.html
Aharon
Ze'ev Clementson
Ok, thanks. Just a minor correction - for iOS 5.0, the browser
shouldn't be listed as Safari 5.1.1, it should just be listed as
Safari (Apple doesn't indicate Safari version numbers for the browser
in iOS so it's not clear what Safari version is included with iOS 5.0
- in any case, it would almost definitely not be the same as the Mac
browser's version number).
Ze'ev
Ze'ev Clementson
On Sun, Oct 30, 2011 at 9:34 AM, Aharon Varady <aharon...@gmail.com> wrote:
> It would be really great to have some javascript to report back on what the
> browser has set as the default character encoding. I've seen browsers set to
> other encodings display Hebrew correctly even when the code should be
> instructing the browser to use utf8. With some JS indicating to the user
> that their browser may not be setup correctly to view a website with Hebrew,
> users could be better informed.
I'm not a web developer so, just to clarify, how could a browser not
be setup correctly to display Hebrew? I would have thought that the
main reasons for Hebrew text not appearing correctly in a browser
would be font-related rather than character encoding related? If an
html page specifies the character encoding to use (UTF-8), why would
the browser not display the page in that character encoding?
Ze'ev
Efraim Feinstein
I *think* that Aharon may be referring to two settings:
(1) The default character encoding -- in a proper web page, this should
never be an issue. The encoding should be declared in the XML
declaration, in a meta tag, and/or in the HTTP response headers.
(2) Some browsers (eg, Firefox) have user-specified default fonts for a
given language.
That's why I don't think the "system font" test is instructive at all
with respect to the browser. It's really testing fallback behavior
that's likely to be different on any computer and for any different
user. If the web designer cares at all about how something exotic (like
Hebrew) will display, he/she should not put much faith in fallback
behavior anyway.
Put another way: Aharon, do you know of any modern browser (that means
not something ancient like IE6 or that's systematically forced to use
another character encoding, like any of the console-based browsers that
rely on the console's settings) that doesn't respect the declared
character encoding?
--
---
Efraim Feinstein
Lead Developer
Open Siddur Project
http://opensiddur.net
http://wiki.jewishliturgy.org
Marc Stober
1. What do you mean: "dagesh preceding all other niqud in letters inlcuding dagesh (dot) and niqud (vowel)"
It sounds like you are saying "dagesh preceding dagesh" but maybe you mean something else? Also there's a typo in "including".
2. I don't have an issue with the system font with IE 9 on Windows 7. If you're still having an issue there let me know and we can try to figure out why you're getting different results than I am.
3. What does the @font-face column mean - how is that different from the Ezra (or Miriam) columns? Is there a reason you don't include a column for the system font result?
4. On the table that includes the reference image you probably want style="text-align: right" (either as an attribute or in the style sheet) rather than align="right"...the latter makes the table float right and the result table wrap around it which I don't think is that you want (the third image attached to Ze'ev message shows this). (Or just not use a table - but I think the align attribute is deprecated on all elements since HTML 4 even though browsers still support it for legacy pages.)
- Marc
--
You received this message because you are subscribed to the Google Groups "opensiddur-tech" group.
To post to this group, send email to opensid...@googlegroups.com.
To unsubscribe from this group, send email to opensiddur-te...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensiddur-tech?hl=en.
--
marcs...@gmail.com ~ www.marcstober.com ~ twitter: marcstober
Aharon Varady
I'm not a web developer so, just to clarify, how could a browser not
be setup correctly to display Hebrew? I would have thought that the
main reasons for Hebrew text not appearing correctly in a browser
would be font-related rather than character encoding related? If an
html page specifies the character encoding to use (UTF-8), why would
the browser not display the page in that character encoding?
Thing is that web browsers will display plain text files just as well as web pages. For the Open Siddur Project, we have plain text files encoded in UTF-8 available for direct download. And since those plain text files do not tell the browser to use any particular character set they look like gibberish when looked at in a browser with the wrong default character encoding.
There may be other good reasons to have this test, but in particular, I want to know what the default character encoding in the browser is for displaying correctly UTF-8 plaintext.
I'm totally open to their being a better test. I'd like some javascript that could report to the user what the default character encoding of their browser is when they access a resource providing UTF-8 in plaintext -- so they'll understand why it looks like gibberish.
Aharon Varady
Hi Aharon,
1. What do you mean: "dagesh preceding all other niqud in letters inlcuding dagesh (dot) and niqud (vowel)"
If the dagesh ([shift +] in the Tiro Hebrew Bible keyboard) is typed after the vowel, rather than before the vowel it is not reliably positioned. For the dagesh to reliably appear within a letter rather than outside it, the sequence it needs to be entered along with the letter and a vowel is: [letter] [shift +] [shift vowel].
It sounds like you are saying "dagesh preceding dagesh" but maybe you mean something else? Also there's a typo in "including".
Help me to rephrase it to be more clear. Thanks for catching the typo.
2. I don't have an issue with the system font with IE 9 on Windows 7. If you're still having an issue there let me know and we can try to figure out why you're getting different results than I am.
It's not so much an issue, but I am recording the different ways that modern web browsers are reporting errors when they can't figure out by the font logic where a unicode glyph should be positioned. In my test of IE9 on Win7 it produces rectangular boxes.
3. What does the @font-face column mean - how is that different from the Ezra (or Miriam) columns?
It means that the browser is rendering the text with the fonts specified in the CSS and HTML. When those fonts render, I know @font-face is supported by the browser.
Is there a reason you don't include a column for the system font result?
It's something which really only has to do with the user's system or browser configuration and is informational to them -- i.e., to let them see what font their browser displays by default without @font-face.
4. On the table that includes the reference image you probably want style="text-align: right" (either as an attribute or in the style sheet) rather than align="right"...the latter makes the table float right and the result table wrap around it which I don't think is that you want (the third image attached to Ze'ev message shows this).
Thanks, Marc.
(Or just not use a table - but I think the align attribute is deprecated on all elements since HTML 4 even though browsers still support it for legacy pages.)
Not sure how to have a table without using a table. Not sure what your suggesting is here.
Efraim Feinstein
On Mon, Oct 31, 2011 at 1:37 PM, Ze'ev Clementson <bere...@gmail.com> wrote:
I'm not a web developer so, just to clarify, how could a browser not
be setup correctly to display Hebrew? I would have thought that the
main reasons for Hebrew text not appearing correctly in a browser
would be font-related rather than character encoding related? If an
html page specifies the character encoding to use (UTF-8), why would
the browser not display the page in that character encoding?
Here's the issue that I've seen. Chrome on Windows and other browsers have their character encoding set by default to ISO-8859-1. Now that shouldn't be a problem when instructed to use UTF-8 in a properly written web page.
Thing is that web browsers will display plain text files just as well as web pages. For the Open Siddur Project, we have plain text files encoded in UTF-8 available for direct download. And since those plain text files do not tell the browser to use any particular character set they look like gibberish when looked at in a browser with the wrong default character encoding.
Ze'ev Clementson
In html pages, it's not a problem because the character encoding can
be specified in the html page (as you've acknowledged in your reply).
In text files that are downloaded over the Internet, you can't use
javascript to test default character encoding because javascript can't
be embedded and executed in text files so I don't know how having
javascript code to test this will be of value in this scenario.
Presumably, a site could specify a default UTF-8 character encoding in
their htaccess file (see here:
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html)
but I'm not a web developer so I don't know how effective this is when
you're serving up text files.
Ze'ev
Aharon Varady
I don't think that's a browser *fail*.
Nor do I. That's why this test is informational to the user and not something I'm recording in the table. Maybe for clarity sake, I should not have it listed as a "test."
In fact, it's correct support of RFC 2616 sec 3.7.1 -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 ; The proper way to handle it is to serve proper HTTP response headers (Content-Type: text/plain; charset=utf-8 ). If the browser ignores *that*, it's a bug.
That's interesting. So even though my plaintext editor (Notepad ++_ can discern what character encoding a given plaintext file was saved in, browsers have no such requirement. Practically, I think you're saying that for our plain text downloads at opensiddur.org, I should have an HTTP response header on all of them.
Efraim Feinstein
On 10/31/2011 04:05 PM, Aharon Varady wrote:
On Mon, Oct 31, 2011 at 2:41 PM, Marc Stober <marcs...@gmail.com> wrote:
Hi Aharon,
1. What do you mean: "dagesh preceding all other niqud in letters inlcuding dagesh (dot) and niqud (vowel)"
If the dagesh ([shift +] in the Tiro Hebrew Bible keyboard) is typed after the vowel, rather than before the vowel it is not reliably positioned. For the dagesh to reliably appear within a letter rather than outside it, the sequence it needs to be entered along with the letter and a vowel is: [letter] [shift +] [shift vowel].
2. I don't have an issue with the system font with IE 9 on Windows 7. If you're still having an issue there let me know and we can try to figure out why you're getting different results than I am.
It's not so much an issue, but I am recording the different ways that modern web browsers are reporting errors when they can't figure out by the font logic where a unicode glyph should be positioned. In my test of IE9 on Win7 it produces rectangular boxes.
3. What does the @font-face column mean - how is that different from the Ezra (or Miriam) columns?
It means that the browser is rendering the text with the fonts specified in the CSS and HTML. When those fonts render, I know @font-face is supported by the browser.
Aharon Varady
http://aharon.varady.net/browser-test-for-hebrew-diacritics.html
Aharon
Efraim Feinstein
> Gathering from the discussion below, I added a simple test that should
> provide user feedback whether UTF-8 is or is not the default character
> encoding for their browser. Just an iframe pointing to a plaintext
> file with UTF-8 encoded Hebrew. The text file does not declare that
> the text is UTF-8 -- so if the browser has ISO-8559-1 set as the
> default that should display as gibberish.
>
> http://aharon.varady.net/browser-test-for-hebrew-diacritics.html
>
What useful information does this tell us? (1) whether the user overrode
the default [useless because it can't be generalized], and (2) whether
the browser is standards compliant [useful, but I think we should assume
standards compliance -- in other words, this "test" should nearly
*always* "fail"].
Ze'ev Clementson
On Mon, Oct 31, 2011 at 1:24 PM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> Unfortunately, the Unicode
> technical committee standardized a particularly stupid canonical order for
> Hebrew vowels and font developers rebelled against it because it was too
> difficult to implement.
Interesting, I hadn't heard this before (I thought font developers
were implementing the Unicode standard) - what was the "stupid
canonical order" that they specified and what did font developers do
instead?
Ze'ev
Aharon Varady
On 10/31/2011 05:23 PM, Aharon Varady wrote:What useful information does this tell us? (1) whether the user overrode the default [useless because it can't be generalized], and (2) whether the browser is standards compliant [useful, but I think we should assume standards compliance -- in other words, this "test" should nearly *always* "fail"].
Gathering from the discussion below, I added a simple test that should provide user feedback whether UTF-8 is or is not the default character encoding for their browser. Just an iframe pointing to a plaintext file with UTF-8 encoded Hebrew. The text file does not declare that the text is UTF-8 -- so if the browser has ISO-8559-1 set as the default that should display as gibberish.
http://aharon.varady.net/browser-test-for-hebrew-diacritics.html
It simply provides information about one's browser settings. This can be useful for troubleshooting when a user complains that the text in their browser looks like gibberish.
Ze'ev Clementson
I think you got the wording reversed in the caption for the iframe.
When I change the default character encoding for the page, all of the
Hebrew text with the EXCEPTION of the text in the iframe appears as
gibberish. The Hebrew text in the iframe looks fine (see attached
screenshot). This is probably because you are serving up the text file
as utf-8 while the current page encoding is being changed by the
browser.
Ze'ev
Efraim Feinstein
Aharon Varady
It would be a reasonable test if the page were served with the Content-Type header.
You're right that if it were served with the Content-Type header and it still came out gibberish something serious would be amiss.
But again I wasn't thinking of this step really as a test, so much as useful information to a user as to what their default browser's character encoding schema is.
I'm not exactly certain how to implement your suggestion in any case, Efraim.
I have a text file pangram-utf8.txt with the following Content-Type header:
Do I need to do anything else? My thinking prior to your post that Content-Type headers were only used in proper web pages (e.g. HTML, XML, etc.)
Aharon
Marc Stober
- Marc
Aharon Varady
Yes. You need a content type header.A plain text file has no metadata to say exactly what encoding it is. Notepad++ and other editors typically can figure it out but when you're going over HTTP, content type header is really the correct way to do it.
Efraim Feinstein
It looks like your server is using Apache. mod_mime <http://httpd.apache.org/docs/2.0/mod/mod_mime.html> will match an extension to a Content-type. There may be easier ways to do it; I'm not exactly an expert on Apache.
Aharon Varady
In the HTML page, yes. In the text file, no. Meta tags in text files are not interpreted at all. Neither the web page, nor the text file are served with any Content-type headers.On 10/31/2011 07:33 PM, Aharon Varady wrote:Am I doing it right? http://aharon.varady.net/browser-test-for-hebrew-diacritics.html
It looks like your server is using Apache. mod_mime <http://httpd.apache.org/docs/2.0/mod/mod_mime.html> will match an extension to a Content-type. There may be easier ways to do it; I'm not exactly an expert on Apache.
Efraim Feinstein
>
> If I'm understanding you right, then to define the Content-Type for a
> text file using the Apache server I'd probably need to write a custom
> .htaccess file to tell the server to serve the .txt files as UTF-8.
Yes. It looks Google-able.
Aharon Varady
Efraim Feinstein
>
> Alternately I could just set the Content-type to plain text, utf-8 in
> an html file, and then put the pangram inside <pre> tags. That might
> be the easiest, if less elegant way.
That would amount to a test of the default sans-serif font (usually,
unless the user changed it).
Aharon Varady
On 10/31/2011 08:25 PM, Aharon Varady wrote:Yes. It looks Google-able.
If I'm understanding you right, then to define the Content-Type for a text file using the Apache server I'd probably need to write a custom .htaccess file to tell the server to serve the .txt files as UTF-8.
http://aharon.varady.net/pangram.txt doesn't have a content-type identified in an .htaccess file, so if one's browser is set to the ISO-8559-1 character set, pangram.txt should probably look like gibberish, right? That is, unless the apache server is set to serve all .txt files as utf8. I'm betting that's what's happening (but I'm not certain).
That might be what's happening on my server (a shared hosting server), since I'm looking at the file info for http://aharon.varady.net/pangram.txt in Firefox and it says the file is UTF8 despite my browser's default character encoding being set back to ISO-8559-1. I expected it to read as gibberish but it's not.
For whatever it's worth I made an .htaccess file for http://aharon.varady.net/pangram-utf8.txt
It looks like this:
<Files pangram-utf8.txt>
ForceType 'text/plain; charset=UTF-8'
</Files>
But if my server is already serving all text files as UTF-8 then that's not going to be very useful, is it?
So I think what's needed is some .htaccess to ensure that pangram.txt will be served without any charset identified -- so as to leave it up to the browser setting -- which is what I wanted to help reveal in the first place.
Aharon
Efraim Feinstein
>
> For whatever it's worth I made an .htaccess file for
> http://aharon.varady.net/pangram-utf8.txt
>
> It looks like this:
>
> <Files pangram-utf8.txt>
> ForceType 'text/plain; charset=UTF-8'
> </Files>
>
> But if my server is already serving all text files as UTF-8 then
> that's not going to be very useful, is it?
>
> So I think what's needed is some .htaccess to ensure that pangram.txt
> will be served without any charset identified -- so as to leave it up
> to the browser setting -- which is what I wanted to help reveal in the
> first place.
You need to look at the actual transmitted headers, not try to reverse
engineer from the display. You can do that with web developer tools,
like Firefox's Firebug extension or Webkit's (eg, Chrome) built-in
developer tools, or you can download the full headers using a command
line HTTP client like curl.
The short answer: No, the Content-type header is not set for either
case. The browser is just identifying it as UTF-8 and serving it that
way. It's a behavior that can't be relied upon.
Aharon Varady
You need to look at the actual transmitted headers, not try to reverse engineer from the display. You can do that with web developer tools, like Firefox's Firebug extension or Webkit's (eg, Chrome) built-in developer tools, or you can download the full headers using a command line HTTP client like curl.
Meanwhile, pangram.txt is displayed however the browser wants to. Even though Chrome 15 and Firefox 10 had ISO-8559-1 set as their default character encoding, they displayed pangram.txt in UTF8.
Somewhat interesting, no? This is a good development for the correct display of Hebrew with diacritics even when browsers ship with non-UTF8 encodings set as the default.
I'm not sure what other useful tests can help with troubleshooting or examining relevant browser behavior for correct display of RTL unicode Hebrew. Unless anyone has any further suggestions, I'm going to leave this page as is, version 0.61, at least for the foreseeable future.
Aharon
Marc Stober
--
You received this message because you are subscribed to the Google Groups "opensiddur-tech" group.
To post to this group, send email to opensid...@googlegroups.com.
To unsubscribe from this group, send email to opensiddur-te...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensiddur-tech?hl=en.
Aharon Varady
Hi Aharon,
The part about the dagesh is more clear now. Thanks.However I've tried two Windows 7 machines with IE9 now (one with MS Office and one without, in case that installed some different font) and neither one produced the rectangular boxes you're describing. See screenshot attached. So I would say that IE9 on Win 7 does fine with the system font.
I think I misled you in my notes on the error for IE9 on Win7. The errors I'm reporting in the table have to do with @font-face in the rendering of Miriam and Ezra only.
My notes say "loud system font positioning error" but what I think I meant was that there are rectangular boxes when it tries to position the ta'amim in Miriam.
Good catch. Stupid error. Sorry for confusing you.
Efraim Feinstein
On 11/01/2011 09:07 AM, Aharon Varady wrote:
>
> My notes say "loud system font positioning error" but what I think I
> meant was that there are rectangular boxes when it tries to position
> the ta'amim in Miriam.
>
>
A fully expected result... Miriam does not support them!
Aharon Varady
On 11/01/2011 09:07 AM, Aharon Varady wrote:
My notes say "loud system font positioning error" but what I think I meant was that there are rectangular boxes when it tries to position the ta'amim in Miriam.
A fully expected result... Miriam does not support them!
Efraim Feinstein
Ze'ev Clementson
Did you miss my question below? I am curious to know the differences
between the Unicode standard and what font developers actually
implement vis-a-vis Hebrew vowels.
Thanks,
Ze'ev
Efraim Feinstein
On 11/01/2011 11:15 AM, Ze'ev Clementson wrote:
> Did you miss my question below? I am curious to know the differences
> between the Unicode standard and what font developers actually
> implement vis-a-vis Hebrew vowels.
>
It's described in some detail (from the font developer's perspective) in
the SBL Hebrew font manual, p8 and Appendix B
<http://www.sbl-site.org/Fonts/SBLHebrewUserManual1.5x.pdf>; Also, note
the differences between Unicode normalization and the typing order
recommended for Ezra SIL font
<http://scripts.sil.org/cms/scripts/render_download.php?&format=file&media_id=EzraSIL2.5Keying&filename=Keying+in+Hebrew.pdf>
Aharon Varady
Hi,It's not a positioning error. It's a missing character.
On 11/01/2011 09:48 AM, Aharon Varady wrote:On Tue, Nov 1, 2011 at 9:26 AM, Efraim Feinstein <efraim.f...@gmail.com> wrote:
On 11/01/2011 09:07 AM, Aharon Varady wrote:
My notes say "loud system font positioning error" but what I think I meant was that there are rectangular boxes when it tries to position the ta'amim in Miriam.
A fully expected result... Miriam does not support them!
For sure, but many browsers do not indicate a positioning error at all. That's the purpose of that test, to see whether the errors are "loud" (e.g. with rectangles) or "quiet" (without any error reporting).
Ze'ev Clementson
On Tue, Nov 1, 2011 at 8:40 AM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> Hi,
>
> On 11/01/2011 11:15 AM, Ze'ev Clementson wrote:
>>
>> Did you miss my question below? I am curious to know the differences
>> between the Unicode standard and what font developers actually
>> implement vis-a-vis Hebrew vowels.
>>
>
> It's described in some detail (from the font developer's perspective) in the
> SBL Hebrew font manual, p8 and Appendix B
> <http://www.sbl-site.org/Fonts/SBLHebrewUserManual1.5x.pdf>; Also, note the
> differences between Unicode normalization and the typing order recommended
> for Ezra SIL font
> <http://scripts.sil.org/cms/scripts/render_download.php?&format=file&media_id=EzraSIL2.5Keying&filename=Keying+in+Hebrew.pdf>
Thanks, those documents were really informative and provide a great
background reference.
Do you know of any utilities that can "correct" older Hebrew documents
created using a different normalization approach if you want to use
text from those documents with a "modern" Unicode font (such as the
SBL, Ezra, Culmus fonts) that applies a different normalized
sequencing? The SIL Converters page
(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=EncCnvtrs)
seems to describe tools that would be suitable for this - are you
familiar with them (or with alternatives)?
Ze'ev
Aharon Varady
For example, in Firefox 10a1 (nightly) on Windows 7, the default font for siplaying Hebrew in the system font test appears to be Narkisim. No where in my browser settings did I indicate that this is the default font... so I'm guessing Firefox is asking Windows what the default system font might be for displaying a serif Hebrew font. But where is this choice stored in Windows and can I change it? I'd ask the same question for all other Operating Systems/Browsers.
Aharon
Efraim Feinstein
On 11/01/2011 12:44 PM, Ze'ev Clementson wrote:
>
> Thanks, those documents were really informative and provide a great
> background reference.
>
> Do you know of any utilities that can "correct" older Hebrew documents
> created using a different normalization approach if you want to use
> text from those documents with a "modern" Unicode font (such as the
> SBL, Ezra, Culmus fonts) that applies a different normalized
> sequencing? The SIL Converters page
> (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=EncCnvtrs)
> seems to describe tools that would be suitable for this - are you
> familiar with them (or with alternatives)
Not that I know of, since it hasn't been a problem I'd encountered
directly. The normalize-nonunicode() XSLT function in the Open Siddur
source basically does it.
Marc Stober
IE seems to be using Times New Roman as a default font, and Firefox is using Narkisim. Times New Roman at least has all the teamim that Narkisim doesn't, but I can't figure out exactly how the browsers decided that, it doesn't even seem consistent with their own settings for Hebrew (IE has David, and while Firefox has Narkisim as the default serif font, it also has a setting to default to san-serif for Hebrew and Arial is the default sans-serif font).
--
You received this message because you are subscribed to the Google Groups "opensiddur-tech" group.
To post to this group, send email to opensid...@googlegroups.com.
To unsubscribe from this group, send email to opensiddur-te...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensiddur-tech?hl=en.
Efraim Feinstein
On 11/01/2011 07:51 PM, Marc Stober wrote:
> Ok, good we're not getting different results on the same browser as OS!
>
> IE seems to be using Times New Roman as a default font, and Firefox is
> using Narkisim. Times New Roman at least has all the teamim that
> Narkisim doesn't, but I can't figure out exactly how the browsers
> decided that, it doesn't even seem consistent with their own settings
> for Hebrew (IE has David, and while Firefox has Narkisim as the
> default serif font, it also has a setting to default to san-serif for
> Hebrew and Arial is the default sans-serif font).
>
There is, of course, one take-home lesson: Don't leave fonts to chance
-- use CSS, and provide a reasonable fallback on all common systems :-)
Aharon Varady
IE seems to be using Times New Roman as a default font, and Firefox is using Narkisim. Times New Roman at least has all the teamim that Narkisim doesn't, but I can't figure out exactly how the browsers decided that, it doesn't even seem consistent with their own settings for Hebrew (IE has David, and while Firefox has Narkisim as the default serif font, it also has a setting to default to san-serif for Hebrew and Arial is the default sans-serif font).
font.default.he (sans-serif)
font.name-list.cursive.he (Guttman Yad, Ktav, Arial)
font.name-list.monospace.he (Fixed Miriam Transparent, Miriam Fixed, Rod, Courier New)
font.name-list.serif.he (Narkisim, David)
font.name.cursive.he (Guttman Yad)
font.name.monospace.he (Fixed Miriam Transparent)
font.name.sans-serif.he (Arial)
font.name.serif.he (Narkisim)
I'm going to switch Ezra SIL for the default serif fonts: Narkisim and David.
Ktav-Yad CLM should replace the default cursive fonts: Guttman Yad, Ktav, and Arial.
Miriam Mono CLM should replace Fixed Miriam Transparent
Taamey David CLM, Miriam CLM or Nachlieli CLM should replace the default sans-serif: Arial.
Aharon
Aharon Varady
I can't explain it. Miriam CLM is now displaying with nearly tolerable diacritic positioning without any empty character markers.
Aharon Varady
http://aharon.varady.net/browser-test/
Shabbat shalom, everyone!
Aharon
Ze'ev Clementson
On Fri, Nov 4, 2011 at 2:52 PM, Aharon Varady <aharon...@gmail.com> wrote:
> I thought the test was getting a bit long and confusing so I split it up
> into separate pages.
>
> http://aharon.varady.net/browser-test/
IMO, there are too many pages to click through and I personally
preferred the all-in-one page.
> Shabbat shalom, everyone!
Shabbat shalom!
Ze'ev
Aharon Varady
IMO, there are too many pages to click through and I personally
preferred the all-in-one page.
If you find this useful, let me know, since I appreciate encouragement.
That goes for everyone's work here. It's the beginning of the dark season, and we can all help each other through it by being extra supportive. I think soon, Efraim or I will send out a call for updates on our respective projects.
Aharon
Marc Stober
What's the use case for this test?
Is this something you direct people to when they complain a problem viewing a document at OpenSiddur.org?
Or is it more intended to help developers (or just yourself) learn so that they can code their sites more effectively?
All are good uses...it would just help give better feedback.
If you want some good news :) I've made a big step forward extracting from the JPS 1917 PDF...I don't have any output to share quite yet but there are a few recent check-ins to my Github account within the past week if you'd find that encouraging.
- Marc
--
You received this message because you are subscribed to the Google Groups "opensiddur-tech" group.
To post to this group, send email to opensid...@googlegroups.com.
To unsubscribe from this group, send email to opensiddur-te...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensiddur-tech?hl=en.
Efraim Feinstein
On 11/07/2011 02:39 PM, Marc Stober wrote:
> What's the use case for this test?
>
> Is this something you direct people to when they complain a problem
> viewing a document at OpenSiddur.org?
>
> Or is it more intended to help developers (or just yourself) learn so
> that they can code their sites more effectively?
This is a good point... I had been thinking about the latter (in which
case, some of the "tests" may serve as warnings against bad practices
like relying on defaults)
>
> If you want some good news :) I've made a big step forward extracting
> from the JPS 1917 PDF...I don't have any output to share quite yet but
> there are a few recent check-ins to my Github account within the past
> week if you'd find that encouraging.
>
Cool -- I noticed that you're working with a branched version 0.4.1 -- a
lot of code has changed since then; if you intend to use any of the
facilities from the rest of the code base, I would suggest merging in
0.4.4 (but not the current master, which has some potential for broken-ness)
Ze'ev Clementson
On Sun, Nov 6, 2011 at 6:56 PM, Aharon Varady <aharon...@gmail.com> wrote:
> On Fri, Nov 4, 2011 at 5:57 PM, Ze'ev Clementson <bere...@gmail.com>
> wrote:
>
>>
>> > http://aharon.varady.net/browser-test/
>>
>> IMO, there are too many pages to click through and I personally
>> preferred the all-in-one page.
>
>
> I mentioned this to Ze'ev just before shabbes in a chat, but the all-in-one
> page still exists and is linked from the index page of the browser test.
>
> If you find this useful, let me know, since I appreciate encouragement.
I personally would have liked to have had something like this a couple
of years ago and I think other developers working with Hebrew text on
different platforms would find it useful. It's helpful to have a
number of good sample cases with reference images for comparison
purposes to validate that your font choices work well and that your
browser and OS can display the Hebrew properly.
Ze'ev
Aharon Varady
Some changes to the tests for Unicode Hebrew text in web browsers:
- I added a new test into the browser tests to see how well browsers were supporting CSS2 @font-face and Hebrew SVG fonts referenced in SVG 1.1 files.
- I validated all of the pages with the w3c.
- I tested Unicode and BIDI support in Lynx, Links, and ELinks.
- I updated the test results with the latest browser versions in Linux and Windows7.
- I added a banner and made some other aesthetic improvements.
I need help testing browsers using iOS, Android 3 and 4, and MacOS. I'm also curious about the Silk browser that the Kindle uses.
I did another cursory look on the Internet for any other browser tests for Hebrew and the ones I found were quite old. I'm not seeing this test in Google's listings yet, so if you think it could be useful to others, please link to it, or adopt, adapt, and redistribute it.
Looking forward, I think a HOWTO or best practices section might be really useful to web developers and website administrators looking to integrate Hebrew into their websites or web applications.
Web browser testing for Unicode Hebrew Text and CSS @font-face (Version 0.7, CC-BY-SA): http://aharon.varady.net/browser-test/
Aharon
Ze'ev Clementson
On Sat, Nov 26, 2011 at 3:38 PM, Aharon Varady <aharon...@gmail.com> wrote:
> Shavuah tov everyone,
>
> Some changes to the tests for Unicode Hebrew text in web browsers:
>
> I added a new test into the browser tests to see how well browsers were
> supporting CSS2 @font-face and Hebrew SVG fonts referenced in SVG 1.1 files.
> I validated all of the pages with the w3c.
> I tested Unicode and BIDI support in Lynx, Links, and ELinks.
> I updated the test results with the latest browser versions in Linux and
> Windows7.
> I added a banner and made some other aesthetic improvements.
>
> I need help testing browsers using iOS, Android 3 and 4, and MacOS. I'm also
> curious about the Silk browser that the Kindle uses.
Here are some Mac OS X 10.7.2 results:
1. Safari 5.1.1: Last two SVG columns are FAIL
2. Mozilla Firefox 9.0: PASS PASS QUIET PASS PASS FAIL* FAIL*
I indicated "FAIL*" for the 2 SVG tests because the SVG text that
Firefox rendered didn't match the shapes of the fonts in the reference
images (see attached svg.jpg file). However, the SVG text WAS
displayed by Firefox while the SVG text wasn't displayed at all in
Safari. So, although according to your wording Firefox does fail at
displaying the exact shapes of the fonts using SVG, it does display
the correct word.
Incidentally, the Firefox 9.0 rendering on my Mac OS X 10.7.2 system
looked at least as good or better (in most cases) than the reference
images you supplied (see attached ezra.jpg and miriam.jpg files).
Hebrew font rendering on the Mac has come a long way in the last few
years!
For iOS 5.0.1 Safari (iPhone), the results are: PASS PASS LOUD LOUD
PASS FAIL FAIL
> I did another cursory look on the Internet for any other browser tests for
> Hebrew and the ones I found were quite old. I'm not seeing this test in
> Google's listings yet, so if you think it could be useful to others, please
> link to it, or adopt, adapt, and redistribute it.
>
> Looking forward, I think a HOWTO or best practices section might be really
> useful to web developers and website administrators looking to integrate
> Hebrew into their websites or web applications.
Yes, I think this would be quite useful as I seem to come across
Hebrew presentation questions quite frequently.
Good work you're doing here Aharon!
Ze'ev
Ze'ev Clementson
> For iOS 5.0.1 Safari (iPhone), the results are: PASS PASS LOUD LOUD
> PASS FAIL FAIL
For iOS 5.0.1 Safari (iPad), the results are the same as iPhone with
one (surprising) exception - the 1st of the SVG tests passes and the
font rendering is identical with the reference image (see attached
screenshot).
- Ze'ev
Aharon Varady
1. Safari 5.1.1: Last two SVG columns are FAIL
2. Mozilla Firefox 9.0: PASS PASS QUIET PASS PASS FAIL* FAIL*
For iOS 5.0.1 Safari (iPhone), the results are: PASS PASS LOUD LOUD
PASS FAIL FAIL
I changed the wording a bit in the results to record first whether the browsers are able to display at all, and second whether they pass the test.
Incidentally, the Firefox 9.0 rendering on my Mac OS X 10.7.2 system
looked at least as good or better (in most cases) than the reference
images you supplied (see attached ezra.jpg and miriam.jpg files).
Hebrew font rendering on the Mac has come a long way in the last few
years!
Send me a good image of them and I'll replace the reference image with yours.
> Looking forward, I think a HOWTO or best practices section might be reallyYes, I think this would be quite useful as I seem to come across
> useful to web developers and website administrators looking to integrate
> Hebrew into their websites or web applications.
Hebrew presentation questions quite frequently.
My first idea was to explain how to:
1. Add Hebrew to web pages using CSS @font-face
2. Make web ready fonts for use with CSS @font-face
3. Make an SVG file with Hebrew styled with CSS @font-face
4. Hack the default Hebrew font settings in Firefox using about:config
Send me your most common HOWTO questions.
I've updated the chart with your FAIL images and results.
Aharon
Ze'ev Clementson
On Sat, Nov 26, 2011 at 9:16 PM, Aharon Varady <aharon...@gmail.com> wrote:
> On Sat, Nov 26, 2011 at 11:07 PM, Ze'ev Clementson <bere...@gmail.com>
> wrote:
>>
>> 1. Safari 5.1.1: Last two SVG columns are FAIL
>> 2. Mozilla Firefox 9.0: PASS PASS QUIET PASS PASS FAIL* FAIL*
>
>> For iOS 5.0.1 Safari (iPhone), the results are: PASS PASS LOUD LOUD
>>
>> PASS FAIL FAIL
>
>
> I changed the wording a bit in the results to record first whether the
> browsers are able to display at all, and second whether they pass the test.
Ok, but I don't think you've updated the table correctly with my
results. Here is the correct html:
<tr><td>iOS 5.0.1</td><td>Safari
(iPhone/iPad)</td><td>PASS</td><td>PASS</td><td>LOUD</td><td>LOUD</td><td>PASS</td><td>FAIL</td><td><a
href="images/Hebrew-font-browser-test-0.70-Safari-iPhone-iOS-5.0.1-svg-test.png">FAIL</a></td><td>Loud
diacritic placement errors with Ezra SIL SR -- "probably @font-face
related because I can display those fonts in a UIWebview without
problems"; no SVG text at all on iPhone but odd partial fail on SVG
CSS @font-face (thanks Ze'ev!)</td></tr>
<tr><td>MacOSX 10.7.2</td><td>Safari
5.1.1</td><td>PASS</td><td>PASS</td><td>QUIET</td><td>PASS</td><td>PASS</td><td>FAIL</td><td>FAIL</td><td>Failed
to display any text in SVG with @font-face</td></tr>
<tr><td>MacOSX 10.7.2</td><td>Firefox
9.0</td><td>PASS</td><td>PASS</td><td>QUIET</td><td>PASS</td><td>PASS</td><td><a
href="images/Hebrew-font-browser-test-0.70-Firefox9-MacOSX10.7.2-svg-test.jpg">FAIL</a></td><td><a
href="images/Hebrew-font-browser-test-0.70-Firefox9-MacOSX10.7.2-svg-test.jpg">FAIL</a></td><td>Displayed
text in SVG but not with correct @font-face</td></tr>
>> Incidentally, the Firefox 9.0 rendering on my Mac OS X 10.7.2 system
>> looked at least as good or better (in most cases) than the reference
>> images you supplied (see attached ezra.jpg and miriam.jpg files).
>> Hebrew font rendering on the Mac has come a long way in the last few
>> years!
>
> Send me a good image of them and I'll replace the reference image with
> yours.
I've attached shots of ezra & miriam.
>> > Looking forward, I think a HOWTO or best practices section might be
>> > really
>> > useful to web developers and website administrators looking to integrate
>> > Hebrew into their websites or web applications.
>>
>> Yes, I think this would be quite useful as I seem to come across
>> Hebrew presentation questions quite frequently.
>
>
> My first idea was to explain how to:
>
> 1. Add Hebrew to web pages using CSS @font-face
>
> 2. Make web ready fonts for use with CSS @font-face
>
> 3. Make an SVG file with Hebrew styled with CSS @font-face
>
> 4. Hack the default Hebrew font settings in Firefox using about:config
>
> Send me your most common HOWTO questions.
The most common ones I can think of at the moment are:
a. How to correctly specify mixed LTR/RTL language positioning at both
the page and element level.
b. How to ensure that Hebrew displays properly (or at least as well as
it can be displayed) on as many browsers as possible (e.g. - font
choices/overrides issues, diacritic correct positioning).
c. How to mix RTL and LTR text in the same paragraph on a page while
preserving correct punctuation positioning.
- Ze'ev
Aharon Varady
Ok, but I don't think you've updated the table correctly with my
results. Here is the correct html:
Sorry for the misunderstanding. The results you sent in show that the browsers *are able* to display SVG, but cannot reliably display SVG with @font-face. Therefore, they pass SVG but fail SVG+@font-face.
> Send me a good image of them and I'll replace the reference image withI've attached shots of ezra & miriam.
> yours.
Thank you!
> Send me your most common HOWTO questions.The most common ones I can think of at the moment are:
a. How to correctly specify mixed LTR/RTL language positioning at both
the page and element level.
b. How to ensure that Hebrew displays properly (or at least as well as
it can be displayed) on as many browsers as possible (e.g. - font
choices/overrides issues, diacritic correct positioning).
c. How to mix RTL and LTR text in the same paragraph on a page while
preserving correct punctuation positioning.
These are great. I think I know the answer to C, and I have an opinion on B but it's probably not satisfactory. Don't know the answer to A but I bet Efraim does. Can you answer these questions Ze'ev?
Aharon
Efraim Feinstein
Here's my 2c:
On 11/27/2011 01:08 AM, Aharon Varady wrote:
> Send me your most common HOWTO questions.The most common ones I can think of at the moment are:
a. How to correctly specify mixed LTR/RTL language positioning at both
the page and element level.
In the CSS, do something like:
:lang(he) {
direction:rtl;
font-family:'BHebrewSR','Ezra SIL', 'Ezra SIL SR', 'SBL Hebrew', 'Cardo', 'Arial Unicode MS', 'Lucida Grande', serif;
}
Note the font family list should begin with the fonts that are downloadable by @font-face, then specify names of fonts that you know work (including the same ones as you served by font-face), then system fonts on common systems that work OK, and only at the end should it specify some kind of default like "serif"
The latter answers b as well:
b. How to ensure that Hebrew displays properly (or at least as well as
it can be displayed) on as many browsers as possible (e.g. - font
choices/overrides issues, diacritic correct positioning).
c. How to mix RTL and LTR text in the same paragraph on a page while
preserving correct punctuation positioning.
Ze'ev Clementson
Gosh, don't you or Aharon sleep? It should be almost 3am on the east coast.
On Sat, Nov 26, 2011 at 11:29 PM, Efraim Feinstein
<efraim.f...@gmail.com> wrote:
> Hi,
>
> Here's my 2c:
>
> On 11/27/2011 01:08 AM, Aharon Varady wrote:
>>
>> The most common ones I can think of at the moment are:
>>
>> a. How to correctly specify mixed LTR/RTL language positioning at both
>> the page and element level.
>
>> Send me your most common HOWTO questions.
>
> Exactly the same way! *Always* specify a lang attribute on the text, *and*
> (not or) xml:lang if you're using XHTML transitional. (I think XHTML strict
> disallows @lang, but I'm not 100% sure).
>
> In the CSS, do something like:
>
> :lang(he) {
> direction:rtl;
> font-family:'BHebrewSR','Ezra SIL', 'Ezra SIL SR', 'SBL Hebrew',
> 'Cardo', 'Arial Unicode MS', 'Lucida Grande', serif;
> }
>
> Note the font family list should begin with the fonts that are downloadable
> by @font-face, then specify names of fonts that you know work (including the
> same ones as you served by font-face), then system fonts on common systems
> that work OK, and only at the end should it specify some kind of default
> like "serif"
You made some good points in an earlier post (some of these are
repeats of what you said in the preceding paragraphs):
(1) make sure the test is valid XHTML 1.0 transitional (the doctype it
declares). Use the W3C validator. It has some basic XML errors that
may make it difficult to parse (that is, the problem can be blamed on
something else). [The CSS *does* validate, with the exception of the
-moz extensions ].
(2) I don't know yet what to report (or to whom). Make a list of all
the display irregularities. Are they caused by something known?
Compare them to supported features. Eg, not every browser claims to
support @font-face , so you can't report bugs against browsers that
don't support it.
(3) Make the fallbacks fonts that don't support Hebrew. That way,
you'll always *know* if @font-face is the failure point. Alternately,
make the second fallback a local copy of the itself and the third be
the font that doesn't support Hebrew.
(4) Make sure you declare "direction:rtl;" and in the "ezra" and
"miriam" classes and declare a new class for the default system fonts
that specifies "direction:rtl;".
(5) declare both xml:lang="he" and lang="he" on the elements that have
Hebrew text.
> The latter answers b as well:
Not completely. I don't think there is a good "universal" fallback font choice.
>> b. How to ensure that Hebrew displays properly (or at least as well as
>> it can be displayed) on as many browsers as possible (e.g. - font
>> choices/overrides issues, diacritic correct positioning).
It's difficult to come up with a standard fallback font that will
display Hebrew with diacritics well in any OS/browser combination.
>> c. How to mix RTL and LTR text in the same paragraph on a page while
>> preserving correct punctuation positioning.
>
> Enclose the paragraph-internal opposite-direction text in a span that does
> not include the punctuation.
That's one option. In what circumstances would you use LTR/RTL marks?
Why or why not?
- Ze'ev
Ze'ev Clementson
>> On 11/27/2011 01:08 AM, Aharon Varady wrote:
>>> Send me your most common HOWTO questions.
Actually, most of the common HOWTO questions for Hebrew & bidi are
answered in the W3C document "Authoring HTML: Handling Right-to-left
Scripts": http://www.w3.org/TR/i18n-html-tech-bidi/#ri20060625.110946746
It would be good to provide a link to that page in your HOWTO section.
- Ze'ev
Aharon Varady
It's been over four months since I last sent an update re: browser support for @font-face Hebrew fonts. Long story short, only two browsers, both on Windows are passing all the tests (IE9 and Chrome 15+). See http://aharon.varady.net/browser-test/browser-test-for-hebrew-diacritics-test-results.html for the test results. (I've added one more column to sort browsers by their rendering engines.)
As you can see, the test results are current for browsers on Windows 7, Linux, Kindle, and Android -- but not on iOS (iPad/iPhone) or Mac OS X browsers (Safari, Opera, Firefox, Chrome) for the CSS @font-face tests. I'm also keen on seeing what support looks like on more advanced Android tablets. (The most advanced Android distribution of Linux I have to test with is v.2.3.4.)
If you have a free moment and run any of these browsers on these OS', send up some screenshots of the following pages. (Make sure your screenshot includes the OS/browser agent ID.)
http://aharon.varady.net/browser-test/browser-test-for-hebrew-diacritics-test2a.html
http://aharon.varady.net/browser-test/browser-test-for-hebrew-diacritics-test2b.html
http://aharon.varady.net/browser-test/browser-test-for-hebrew-diacritics-test3.html
Finally, if you're wondering why AppleWebKit 535.11 is acting slightly differently under Chromium on Linux and under Chrome on Windows in presenting a shuruk correctly and have enough interest to fire up fontforge to test whether the ligature I created (vav + dagesh) has some problem that is causing the error, please help. I'm attaching the Linux Libertine Serif font that I hacked with fontforge to include the shuruk letter combination. Not sure why a shuruk is displaying without trouble with MiriamCLM but not with Linux Libertine.
Thank you.
Adar Sameaḥ,
Aharon
Aharon Varady
Still looking for screenshots of the latest Chrome, Firefox, Opera, and Safari on MacOS X. See below for the links.
Aharon
Ze'ev Clementson
Here are the results for Mac OS X 10.7.3:
Safari 5.1.3: Exactly same as the results for Safari 5.1.1.
Firefox 11.0: Exactly same as the results for Firefox 9.0.
Chrome 17.0.963.66: Exactly same as the results for Chrome 15.0.874.121.
Opera 11.61: Exactly same as the results for Opera 11.60.
Since the results were identical for all browsers, I haven't updated
the screen shots.
Ze'ev