CDRF and WICD profiles are Candidate Recommendations, Call for Implementations

Hi.

I was able to modify the current Safari 3.02 browser
(actually it's  
Webkit rendering engine), for it to support "WICD
Rightsizing".

Lars and I then created some dedicated WICD content, to show
the  
difference in behavior. Finally, we did a screen capture of
how the  
two browsers render that content. A video of this is now
available  
online. Hope you like it.

Timur

http://timur.mobi/wicd-s
tuff (Rightsizing Demo, 60 sec / 10 MB)


On 24.07.2007, at 00:02, Kevin E Kelly wrote:

> Compound Document Formats: Call for Implementations
>
>   The Compound Document Formats Working Group has
released four
>   Candidate Recommendations: "Compound Document by
Reference Framework
>   1.0," "WICD Core 1.0," "WICD Full
1.0," and "WICD Mobile 1.0."
>   Implementor feedback is welcome through 1 December. A
preliminary
>   implementation report is available, and a test suite
is under
>   development. The Web Integration Compound Document
(WICD, pronounced
>   "wicked") is a device independent Compound
Document profile based on
>   XHTML, CSS and SVG. The drafts describe presentation,
linking and
>   navigation behavior when multiple documents are
combined. Read more
>   about Rich Web Clients.
>
>   http://www
.w3.org/TR/2007/CR-CDR-20070718/
>   http://ww
w.w3.org/TR/2007/CR-WICD-20070718/
>   http:
//www.w3.org/TR/2007/CR-WICDFull-20070718/
>   htt
p://www.w3.org/TR/2007/CR-WICDMobile-20070718/
>   h
ttp://www.w3.org/2004/CDF/CDR-implementations.html
>   http://www.w3.org/2006/rw
c/
>   http://www.w3.org/2004/CD
F/
>
> Kevin Kelly
> Chair, Compound Document Format Working Group
>

On 12.09.2007, at 10:58, Maciej Stachowiak wrote:

>> I was able to modify the current Safari 3.02
browser (actually  
>> it's Webkit rendering engine), for it to support
"WICD Rightsizing".
>>
>
> Out of curiosily, what kind of changes were needed?
>
>  - Maciej

Sorry for the late response. It's a while back, since I
looked into  
this. But basically, this is what I did.

The HTML parent object element needs to be made aware of the
aspect  
ratio of the embedded SVG child, as expressed by it's
viewbox. So I  
modified method setViewBox() in WebCore/rendering/ 
RenderSVGContainer.cpp, for it to call
node->document()->frame()- 
 >ownerRenderer()->setIntrinsicSize() - I do so only,
if ownerRenderer 
() exist - and I provide it with the values of
viewBox.width() and  
viewBox.height(). Then I modified method
calcReplacedHeightUsing() in  
WebCore/rendering/RenderBox.cpp, so that it makes use of
it's newly  
gained knowledge about the child's aspect ratio. This way,
SVG  
children are not anymore shown in a fix 300 x 150 px box.

SVG children can now, for example, be embedded with a width,
that is  
relative to their destination box. And their final height
will be  
calculated, based on the relative width and their intrinsic
aspect  
ratio.

My bug report and my patch are attached below.

Timur

http://b
ugs.webkit.org/show_bug.cgi?id=14793