Re: [svg-developers] Re: indic language support

"Chris Lilley" <>

Full Quoted, and added so it's public for referencing

> On Friday, April 26, 2002, 12:27:17 PM, Jim wrote:
> JL>
> JL> .svg
> JL> Your suggesting a font-family though, it should be working without
> JL> need of doing that
> If it has a suitable fallback font pre-configured.

This is completely different to my understanding, if a character is not
found in the browsers font, it is to find the character in any available
font, my understanding was brought from such pages as and
related (follow the links.) Which suggests this is mandated by
RFC2070/HTML 4.0 - I don't have the opportunity currently to research this
in detail to see if this is the case I'm stretching the limits of my
knowledge going this far, but if my understanding is wrong then the web is
in a _very_ serious state as regards to i18n it's impossible to support
users who have "use my own font" for i18n issues unless that font has
every character in existence.

> JL>  AIUI, it does in HTML with modern browsers.
> No, only if the user picks an appropriate font.
> JL>  How are
> JL> we to know which fonts a user has that contains a particular
> Well, that is what downloadable fonts are for and that is why it is a
> priority ordered list not a single value.
> JL> You're pretty much relying on MS Arial Unicode, and Code 2000 by the
> JL> looks of things, whilst they're common enough for containing all
> JL> if you're just wanting one of the languages characters you'll
probably be
> JL> using a less demanding font.
> Yes. I would welcome suggestions for specific fonts for any of those
> languages for any platform.

Moomin OS 7 uses the font Snufkin Lite for Urdu  HTH.

> JL>  is the same without the
> JL> suggestions, which should still work, but doesn't in ASV other than
> JL> Farsi and Urdu
> (For some definition of 'work' - ASV3 does not display arabic scripts
> correctly). However, ASV3 also has a known bug with font lists - if
> the first font family in a list is found, but does not have the right
> glyphs for (some/all) of the content, it fails to move on to the
> second and subsequent fonts in the list.
> I tried your file in Batik 1.5b1 but it complained about an invalid
> property value "". From a look at your source, this is a bug in Batik.
> JL> - My browser is pretty happy normally with fonts, and I
> JL> have all the characters.
> Meaning, your (HTML) browser is already configured to pick a suitable
> font, and ASV3 is not so configured (mainly because it does not have a
> UI for such configuration).
> JL> (I don't send image/svg+xml; charset=utf-8
> JL> which perhaps I should,
> There is no charset parameter defined for image types.
(a draft, and I don't follow the exact issues, so my interpretation is
potentially wrong...)

"Because encoded text cannot be interpreted and processed without knowing
the encoding, it is vitally important that the character encoding [...] is
known at all times and places where text is exchanged or processed. "

"When text transmitted as a byte stream is involved, for instance in a
protocol, specification of a CES is required to ensure proper
interpretation;"  (CES stands for character encoding scheme  "A CES is a
mapping of the code units of a CEF into well-defined sequences of bytes"

Which seems to be saying to me that when text is transmitted via a
protocol such as http you need to include what the CES is to allow for it
to be processed correctly (It seems to me that saying inside the file is
too late if you're using 8 or 16 or whatever byte CES's) indicates
you were discussing the registration including the charset issue, it
clearly needs one as an XML document, rfc3023 says this "In particular,
the charset parameter SHOULD be used in the same manner, as described in
Section 7.1, in order to enhance Interoperability."  - Okay it was only
SHOULD, but I'd like to see some very good justification of why you're
going against this. (Perhaps in the registration of image/svg+xml )

> JL> but then thinks its image/svg...)
> Really! Hmm I will send them a bug report.
> --
>  Chris                  


Received on Sunday, 28 April 2002 17:13:46 UTC