W3C home > Mailing lists > Public > www-svg@w3.org > June 2003

Re: Request for onGlyphFailed Event

From: Thomas E Deweese <thomas.deweese@kodak.com>
Date: Wed, 4 Jun 2003 08:01:44 -0400
Message-ID: <16093.57256.391241.427058@frog.rl.kodak.com>
To: Jim Ley <jim@jibbering.com>
Cc: www-svg@w3.org

>>>>> "JL" == Jim Ley <jim@jibbering.com> writes:

JL> "Dean Jackson" <dean@w3.org>
>> Can I try rewording it?

JL> I'd hope so!  If it got put in straight like that, I'm sure I'd
JL> have lots to moan about.

>> You want the UA to fire an event before (or as) it draws any
>> missing
JL> glyph.
>> I assume you don't want it constantly firing, so it would just be
>> on first processing. What happens if I change the font-family
>> property on the text, does it fire again (unless the glyph is found
>> this time)?

JL> I'm really not sure, I've just got a problem I want to solve :-)
JL> It may need to be constantly firing for each glyph so I can
JL> construct a list of what I need to get.

    Thinking about this an entirely different way, how about adding a
method such as 'int canDisplayUpTo(String s, int start, int limit)'
(This is taken from Java's Font API) to the font-face element in the
DOM.  This allows you to find out what portion of a string a
particular font-face can (or can't) render.

    It occurs to me that waiting for the event to be triggered during
rendering is really _way_ late.  The above method would allow you to
query ahead of time if particular font-face's could render the text
string you have.  This also keeps event generation out of the
rendering engine (something that I think is a real must).

JL> Changing font-family should probably have it fire again, unless
JL> there's an alternative idea where it fires once for any missing
JL> glyph and then which glyphs in the document have failed can be
JL> obtained from another property.

>> One problem might be that a few SVG viewers hand off all that
>> complicated text rubbish to a platform text library. I'm not sure
>> if they can always get this information back.

JL> Well, with getBBox we can sort of infer it now, so they could have
JL> a hack approach, but I agree it could be problematical.

   I think the above would be easier to implement in these cases as
generally answering the above query would require little understanding
of the text - all layout issues for example can be totally ignored.
Received on Wednesday, 4 June 2003 08:03:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:56 UTC