Community
Participate
Working Groups
If an image tag is specified in the XML (imagedata from DocBook), we need to support the rendering of this using the background-image element from CSS. This takes url attribute with the location to the image, which should be retrieve from the fileref attribute. More information on how images can be handled: http://www.csstutorial.net/css_misc_images.php Typically I'll have something like the following from the XSLT Docbook documentation for XSL Tools: <figure id="fig_XSLProposals"> <title>XSLT Proposals within Non-XSLT elements</title> <mediaobject> <imageobject> <imagedata align="center" fileref="../images/editor/xslproposals.png"/> </imageobject> </mediaobject> </figure> The figure will be a container block and the image displayed inline.
*** Bug 321862 has been marked as a duplicate of this bug. ***
Please see also https://bugs.eclipse.org/bugs/attachment.cgi?id=175944
(In reply to comment #2) > Please see also https://bugs.eclipse.org/bugs/attachment.cgi?id=175944 Cool. If you do use this code (i.e. it is still relevant), please contact the author and see if he would give permission to use it. It looks less than 250 lines of code total, so shouldn't have to go through IP review, but would be good to mark in the log if he does give permission to use it.
The other thing is that this should probably go into a DocBook specific extension or be made so that Plugins can contribute information about what tags contain graphic images if we can't determine directly from the CSS.
Created attachment 175972 [details] applied the changes described in attachment 175944 [details] to vex.core
Created attachment 175973 [details] applied the changes described in attachment 175944 [details] to vex.core.tests
Created attachment 175974 [details] applied the changes described in attachment 175944 [details] to vex.ui
I created a set of patches with the changes described in https://bugs.eclipse.org/bugs/attachment.cgi?id=175944 as a base for further discussions, annotated with some comments where IMHO some action is still needed: * the changes depend on a specifc DTD (with a <graphic> element that has an attribute @url) * the changes introduce some new dependencies to SWT where it is better to have none Mohamadou, thank you for the contribution. It is a good starting point for further development. As Dave already mentioned, we need your permission to use your code. So please add a comment if you agree, a simple "Yes you can" will do it. (BTW: It's nice to see that there is some love for Vex in my former university in Würzburg.)
(In reply to comment #4) > The other thing is that this should probably go into a DocBook specific > extension or be made so that Plugins can contribute information about what tags > contain graphic images if we can't determine directly from the CSS. > I agree: the URL of the image should not be hard-coded. We should use the CSS attr function. Maybe: HTML img element: img { background-image:url(attr(src)); } TEI graphic element: graphic { background-image:url(attr(url)); } Docbook imagedata { background-image:url(attr(fileref)); } See also: <http://stackoverflow.com/questions/1044808/what-is-the-correct-usage-of-css-attr-function>
(In reply to comment #8) > I created a set of patches with the changes described in > https://bugs.eclipse.org/bugs/attachment.cgi?id=175944 as a base for further > discussions, annotated with some comments where IMHO some action is still > needed: > * the changes depend on a specifc DTD (with a <graphic> element that has an > attribute @url) > * the changes introduce some new dependencies to SWT where it is better to > have none > > Mohamadou, thank you for the contribution. It is a good starting point for > further development. As Dave already mentioned, we need your permission to use > your code. So please add a comment if you agree, a simple "Yes you can" will do > it. (BTW: It's nice to see that there is some love for Vex in my former > university in W�rzburg.) Yes you can. This was actually a test, I am going to implement what Mr. Holger Voormann has suggested. However CSS2 specification (http://www.w3.org/TR/CSS2/generate.html) mentions that attr() is used in conjunction with content property in pseudo-elements. Well I have already implemented attr() function. It would not be a problem to use it as value of background-image property. But if we use it in this way (see below), I think we are violating CSS2 rules. I have not found changes related to attr() in CSS3 as well. Or am I misunderstanding the specifications ? [ HTML img element: img { background-image:url(attr(src)); } TEI graphic element: graphic { background-image:url(attr(url)); } Docbook imagedata { background-image:url(attr(fileref)); } ]
CSS 3 exapnds the uses of the attr() method and allows it be used anywhere: http://www.w3.org/TR/css3-values/#attribute (In reply to comment #10) > (In reply to comment #8) > > I created a set of patches with the changes described in > > https://bugs.eclipse.org/bugs/attachment.cgi?id=175944 as a base for further > > discussions, annotated with some comments where IMHO some action is still > > needed: > > * the changes depend on a specifc DTD (with a <graphic> element that has an > > attribute @url) > > * the changes introduce some new dependencies to SWT where it is better to > > have none > > > > Mohamadou, thank you for the contribution. It is a good starting point for > > further development. As Dave already mentioned, we need your permission to use > > your code. So please add a comment if you agree, a simple "Yes you can" will do > > it. (BTW: It's nice to see that there is some love for Vex in my former > > university in W�rzburg.) > > > Yes you can. > > This was actually a test, I am going to implement what Mr. Holger Voormann has > suggested. However CSS2 specification (http://www.w3.org/TR/CSS2/generate.html) > mentions that attr() is used in conjunction with content property in > pseudo-elements. Well I have already implemented attr() function. It would not > be a problem to use it as value of background-image property. > But if we use it in this way (see below), I think we are violating CSS2 rules. > I have not found changes related to attr() in CSS3 as well. > Or am I misunderstanding the specifications ? > > > [ > HTML img element: > img { background-image:url(attr(src)); } > > TEI graphic element: > graphic { background-image:url(attr(url)); } > > Docbook > imagedata { background-image:url(attr(fileref)); } > > ]
In particular, from the CSS3 specification: Ideally, it shouldn't be necessary to specify the type if it is obvious. For example, this should be valid: "background-image: attr(href);". This could be described as: "If the property only accepts one type of value (aside from 'inherit' and 'initial'), that type is implied".
(In reply to comment #10 and comment #12) > In particular, from the CSS3 specification: > > Ideally, it shouldn't be necessary to specify the type if it is obvious. For > example, this should be valid: "background-image: attr(href);". This could be > described as: "If the property only accepts one type of value (aside from > 'inherit' and 'initial'), that type is implied". +1 Mohamadou, what do you think: could we use this syntax ("background-image: attr(<attribute-name>);") from the CSS3 draft specification?
(In reply to comment #13) > (In reply to comment #10 and comment #12) > > In particular, from the CSS3 specification: > > > > Ideally, it shouldn't be necessary to specify the type if it is obvious. For > > example, this should be valid: "background-image: attr(href);". This could be > > described as: "If the property only accepts one type of value (aside from > > 'inherit' and 'initial'), that type is implied". > +1 > > Mohamadou, what do you think: could we use this syntax ("background-image: > attr(<attribute-name>);") from the CSS3 draft specification? Well if I understand the specification ((http://www.w3.org/TR/css3-values/#attribute)), it does not mention that attr() could be used on any property. Therefore I assume that CSS2 rule is maintained, which says that attr() is employed with generated content. The background-image property as described here (http://www.w3.org/TR/css3-background/#the-background-image) does not say that attr("xyz") could be one of its values. To the contrary it shows that url("xyz") should be used. Or am I missing something ?
(In reply to comment #14) > Well if I understand the specification > ((http://www.w3.org/TR/css3-values/#attribute)), it does not mention that > attr() could be used on any property. Therefore I assume that CSS2 rule is > maintained, which says that attr() is employed with generated content. > > The background-image property as described here > (http://www.w3.org/TR/css3-background/#the-background-image) does not say that > attr("xyz") could be one of its values. To the contrary it shows that > url("xyz") should be used. > > Or am I missing something ? > The example "background-image: attr(href);" is given by the CSS3 specification: http://www.w3.org/TR/css3-values/#attribute For me the specification itself is not so clear. Probably "background-image: attr(href, url);" is valid too.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #10 and comment #12) > > > In particular, from the CSS3 specification: > > > > > > Ideally, it shouldn't be necessary to specify the type if it is obvious. For > > > example, this should be valid: "background-image: attr(href);". This could be > > > described as: "If the property only accepts one type of value (aside from > > > 'inherit' and 'initial'), that type is implied". > > +1 > > > > Mohamadou, what do you think: could we use this syntax ("background-image: > > attr(<attribute-name>);") from the CSS3 draft specification? > > > Well if I understand the specification > ((http://www.w3.org/TR/css3-values/#attribute)), it does not mention that > attr() could be used on any property. Therefore I assume that CSS2 rule is > maintained, which says that attr() is employed with generated content. > > The background-image property as described here > (http://www.w3.org/TR/css3-background/#the-background-image) does not say that > attr("xyz") could be one of its values. To the contrary it shows that > url("xyz") should be used. > > Or am I missing something ? The CSS3 specification at (http://www.w3.org/TR/css3-values/#attribute) says that "background-image: attr(href);" is valid if the type is obvious. However it does not state that attr() could be used under any selector, I mean non generated content (pseudo-elements, pseudo-classes). Or am I missing something ?
(In reply to comment #16) > > The CSS3 specification at (http://www.w3.org/TR/css3-values/#attribute) > says that "background-image: attr(href);" is valid if the type is obvious. > > However it does not state that attr() could be used under any selector, I mean > non generated content (pseudo-elements, pseudo-classes). > > > Or am I missing something ? According to http://www.w3.org/TR/css3-values/#attribute this details is not clear yet: "Should 'attr()' be allowed on any property, in any source language? For example, do we expect UAs to honor this rule for HTML documents?: P[COLOR] { color: attr(COLOR, color) }." But: we need some kind of configuration per document type, which elements can contain images, and how are the images referenced.. For other elements (e.g. tables) this kind of configuration is done in the CSS. So I would prefer this for images, too.
(In reply to comment #15) > (In reply to comment #14) > > Well if I understand the specification > > ((http://www.w3.org/TR/css3-values/#attribute)), it does not mention that > > attr() could be used on any property. Therefore I assume that CSS2 rule is > > maintained, which says that attr() is employed with generated content. > > > > The background-image property as described here > > (http://www.w3.org/TR/css3-background/#the-background-image) does not say that > > attr("xyz") could be one of its values. To the contrary it shows that > > url("xyz") should be used. > > > > Or am I missing something ? > > > The example "background-image: attr(href);" is given by the CSS3 specification: > http://www.w3.org/TR/css3-values/#attribute > For me the specification itself is not so clear. Probably "background-image: > attr(href, url);" is valid too. Yes it is valid as well. In fact the specification says that if the <type> is missing, 'string' is implied. Therefore "background-image: attr(href);" is also valid because url is assumed to be a string. Or do you see it differently?
(In reply to comment #17) > (In reply to comment #16) > > > > The CSS3 specification at (http://www.w3.org/TR/css3-values/#attribute) > > says that "background-image: attr(href);" is valid if the type is obvious. > > > > However it does not state that attr() could be used under any selector, I mean > > non generated content (pseudo-elements, pseudo-classes). > > > > > > Or am I missing something ? > > According to http://www.w3.org/TR/css3-values/#attribute this details is not > clear yet: > > "Should 'attr()' be allowed on any property, in any source language? For > example, do we expect UAs to honor this rule for HTML documents?: P[COLOR] { > color: attr(COLOR, color) }." > > But: we need some kind of configuration per document type, which elements can > contain images, and how are the images referenced.. For other elements (e.g. > tables) this kind of configuration is done in the CSS. > > So I would prefer this for images, too. Yes, which elements can contain images, and how are the images referenced, need to be clarified. Otherwise we just stick to the following: HTML img element: img { background-image:url(attr(src)); } TEI graphic element: graphic { background-image:url(attr(url)); } Docbook imagedata { background-image:url(attr(fileref)); }
(In reply to comment #19) > Yes, which elements can contain images, and how are the images referenced, need > to be clarified. > I would expect to have this information in the CSS only: if and only if an element has the style "background-image". The image URL is given either static: "background-image:url(file:///C:/path/image.png);" or by the attribute value for the element 'instance': "background-image:attr(src);" -> assuming in the XML file there is for instance "<element src="file:///C:/path/image.png"/>". If it's a relative URL then in the first (static) case the base directory is the directory containing the CSS file and in the second (attr()) case the directory containing the XML file. What are the alternatives? Could you please make an example? Does this work also when switching the style?
(In reply to comment #20) > (In reply to comment #19) > > Yes, which elements can contain images, and how are the images referenced, need > > to be clarified. > > > I would expect to have this information in the CSS only: if and only if an > element has the style "background-image". The image URL is given either static: > "background-image:url(file:///C:/path/image.png);" or by the attribute value > for the element 'instance': "background-image:attr(src);" -> assuming in the > XML file there is for instance "<element src="file:///C:/path/image.png"/>". > > If it's a relative URL then in the first (static) case the base directory is > the directory containing the CSS file and in the second (attr()) case the > directory containing the XML file. > > What are the alternatives? Could you please make an example? > > Does this work also when switching the style? In addition you'll want to get the image height and width, and possibly the role if you are using DocBook. The alternative is a special plugin for the various XMLs to handle the images and specific element content. I'd rather as you said stick with CSS and make sure we do as much as possible in the CSS stylesheets when it comes to rendering and styling of the content.
I created a new branch bug298912_vex_image_support with the attached changes. Please use this branch for the further development of the image support.
Created attachment 178751 [details] Understanding Vex Rendering Engine, and source code for supporting image and CSS pseudo-elements This attachment contains source code for supporting image display whereby the attr(url) could be used to retrieve the attribute url from a graphic element. Additionally support for some CSS pseudo-elements has also been done. The paper is an introduction to Vex rendering engine with the purpose of easing the task of those who would like to factor or extend Vex rendering and layout functionalities.
Support for image display has been updated, as well as some CSS pseudo-elements. Additionally a simplified introduction to Vex rendering engine has been included in the attached paper.
(In reply to comment #24) > Support for image display has been updated, as well as some CSS > pseudo-elements. > Additionally a simplified introduction to Vex rendering engine has been > included in the attached paper. Hi Mohamadou, thank you for your paper. I believe that it's helpful even if it describes the old SourceForge version of Vex (net.sf.vex). I created a link to it on the Vex home page http://wiki.eclipse.org/Vex Have you considered upgrading Vex from the SourceForge to the Eclipse version in Textgrid? Eclipse Vex is newer and has more features, for instance Find/Replace, Commands instead Actions, etc. It would be nice if Textgrid participated more in the current Vex development instead of hosting its own forge.
Comment on attachment 178751 [details] Understanding Vex Rendering Engine, and source code for supporting image and CSS pseudo-elements I applied all changes proposed in the attached paper to the feature branch. Images are displayed, but there is still some work to do, to make it nice and efficient.
Just for the IP record, the changes based on Mohamadou's paper are in the following commits: http://git.eclipse.org/c/webtools/org.eclipse.webtools.incubator.git/commit/?h=bug298912_vex_image_support&id=47bde0e72c44341fd9d051c362d953ac663cdb50 http://git.eclipse.org/c/webtools/org.eclipse.webtools.incubator.git/commit/?h=bug298912_vex_image_support&id=7295de12768cef6f6e11f2f9353cb25549712d6c http://git.eclipse.org/c/webtools/org.eclipse.webtools.incubator.git/commit/?h=bug298912_vex_image_support&id=2dcb382c839006042006ab29cb10d0894af5fda8
Just some words about the implementation: Images represented in the box model by instances of ImageBox. Those are added to the contents of BlockElementBox or InlineElementBox if the background-image property has a value. To support the most frequent case, where the URL of an image is stored as attribute value, you have to define the background-image property in the CSS as discussed above: image-element { background-image: attr(image-url-attr); } Relative image URLs are resolved based on the base URL of the document. The usage of xml:base is also supported (see http://www.w3.org/TR/DOM-Level-3-Core/core.html#baseURIs-Considerations for more information on that). Internally the class org.eclipse.swt.graphics.Image is used to load and display the image. So Vex supports only the image formats that can be handled with SWT.
I tried this out, and while it does display the image at least in the default configuration, the images are really, really, really tiny. Does the parent container need to specify a minimum Width and Height, and is there a way to get a default width and height from the url. Docbook specifies a contentdepth and contentwidth set of attributes that can be used, as well as a scaletofit attribute.
(In reply to comment #29) The current implementation differs between block elements and inline elements. In block elements, Vex tries to show the image in its original size, but scales it to the width of the containing element, if the image is bigger. In inline elements, the image is scaled to the height of the current line (or shown in full size, if it is smaller than the current line height). > Docbook specifies a contentdepth and contentwidth set of attributes that can be > used, as well as a scaletofit attribute. See also bug 329636.
Closing resolved bugs.
Moved to Mylyn Docs Vex.
