Re: SVG 1.2 Comment: 4 Flowing text and graphics

"David Woolley" <david@djwhome.demon.co.uk> wrote in message 
news:200411072033.iA7KXI002257@djwhome.demon.co.uk...
>
>> Consistency is needed. I want to check if it looks right on one client 
>> only.
>
> But you have never seen the data in question.  If you do have the data
> locally, you, or your authoring tools can send explicitly broken lines.

No we can't, since we do not know the exact font metrics in our server side 
tools, it's equally silly to build the font metric knowing ability into our 
server side tools when the SVG UA already needs to know them.  We have a 
choice, build it into our authoring tools - at huge development cost, and 
still limit what we can do.

David, can you please realise that the Authoring Tool for many of us is the 
client, because SVG is just a rendering language, and we feel it's key for 
accessibility and consistency to keep the data in a semantic format until it 
is rendered.  A solution involving authoring tools is of no use to us.

> The argument being made was that you needed consistent reproduction
> of data imported from third party, non-SVG, sources, such as GEDCom
> family tree files.

Yes, and I do that transformation on the client in SVG, but I can't display 
much of the text from them, because developing the layout algorithm in 
client-side javascript is too slow, and too expensive.  For the RDF gedcom 
into svg example, you can see it here - 
http://jibbering.com/nauts/gedcom/foafnaut.svg - it's not all that neat, and 
it's not accessible, but that's through lack of time for what is a toy demo 
done for an RDF gedcom developer.  What it does allow though is that the 
same rich semantic data is shared between the user, and the SVG, encouraging 
the authoring of the semantic data (as it doesn't need to be then 
re-authored into a rendered format.)

Jim.

Received on Sunday, 7 November 2004 21:23:08 UTC