[sldev] [VWR] What about Dillo

[Joshua Bell]

To be pedantic...

Argent Stonecutter wrote:
> llRenderSVG(0, "<svg width=1m height=1m viewbox='0 0 256 256'><text 
> x=2 y=10 font-family=Courier font-size=22 fill=black>Hello 
> World</text></svg>");
>
> Adding all the doctype stuff would more than double the size, and LSL 
> strings are limited length.
>
> llRenderHTML(0, "<div style='font:22pt 
> Courier;color:black;text-align:center'>Hello World</div>");
>
> HTML is a more compact representation for text, and less specific data 
> needs to be specified. Should the SVG viewbox be an actual section of 
> the texture, or the width and height be absolute, or should they be 
> mapped to the whole texture or prim face respectively, allowing you to 
> generate SVG independent of the size of the prim or texture? Assuming 
> mapping, you could implement llRenderText either way...
That snippet of HTML leaves quite a bit of detail to the implementation 
- the DIV is not given a size and since it's a fragment most of the 
presentation (size, background color, wrapping, etc) is undefined. (In 
HTML, you might want to specify the doctype as well to handle versioning.)

If I recall correctly (and I confess to being in the VML camp the last 
time I dug into the standards, sorry!), the SVG output should be pretty 
consistent regardless of the implementation, but by design most HTML 
rendering (without heavy use of CSS) is up to the rendering layer. I'd 
hate to couple the standard for display of SL content to any particular 
renderer implementation (e.g. Gecko vs. ...?) or we fall into the Quirks 
Mode hell of the web.

(This is all scoped to the "lightweight dynamic textures" part of the 
discussion. I think for generalized HTML-on-a-Prim the content authors 
should not be assuming more from the "browser" platform provided than 
web content authors today, and users who do care about precise 
representation will be doing hard-core CSS and expecting some degree of 
conformance a la the Acid Tests, which is a lot more reasonable to 
expect from a variety of implementations, but at the expense of far more 
verbose markup.)

Joshua