fine-tuning XHTML ouput

I do realise the conversion/output options are provided by way of example, and indeed that it's not
difficult to open the xhtml source in an editor afterwards ... but I was wondering if there was any simple
way of persuading the conversion to leave references to svg graphics untouched. If I've made the choice to
deliver referenced graphics as svg, it's a bit surprising that the tool then knows better and generates
png versions.

Niels Grundtvig Nielsen
Technical Author - Safety Management Unit
The Brussels Airport Company
tel +32 (0)2 753 66 74
www.brusselsairport.be
_____________________________________________
This message, including attachments, is confidential and may be privileged.
If you are not an intended recipient, please notify the sender then delete and destroy the original message
and all copies. You should not copy, forward and/or disclose this message, in whole or in part, without
permission of the sender.

--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support

Re: Moving chapter nodes

Hussein Shafie wrote:
> It works like everything else in XMLmind XML Editor. The only trick you
> need to know is: you cannot replace the root element of a document;
> however you can replace all its children using a single paste command.
>
> [1] Select chapter A in the master document M.xml.
> [2] "Esc Down_Arrow" to select all the children of chapter A.
> [3] Ctrl-C to copy all the selected nodes to the clipboard.
> [4] Create a new chapter document. Switch to this new chapter document.
> Let's call it C.xml.
> [5] Select the empty chapter which is the root of C.xml.
> [6] "Esc Down_Arrow" to select all the children of the empty chapter.
> [7] Ctrl-V to replace these children by the contents of chapter A (used
> here the above trick).
> We consider that this operation is seldom needed, otherwise we would
> have implemented a specific command to perform it.
>   
Dear Mr. Hussein,

Just for your information, we perform this operation very frequently.

It's a common situation in our case not to know in advance which parts 
(sections/chapters/...) of a document will eventually be shared.

Another similar thing we often do (we use the same procedure) is turning 
chapters into sections and conversely, appendix into chapters, etc....  
The rationale is the same (== not knowing in advance how documents parts 
will be organized and shared among documents).

For all these cases, the copy and paste of children works fine, but this 

Re: Problem with xxe 4.2.0 and Java 1.6.0.15/1.6.0.16 on Kubuntu 9.10

--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support

Re: Problem with xxe 4.2.0 and Java 1.6.0.15/1.6.0.16 on Kubuntu 9.10

Kevin Flynn wrote:
> OK, thanks for the information. I'm not 100% certain, but I'm pretty
> sure I was running a 1.6 release before I upgraded to kubuntu 9.10, and
> I had no problem then, so maybe not all 1.6 releases have the problem.
> If I continue to have luck with 1.6.0.10, I will let you know. If I
> don't, then I'll try the clipboard workaround you mentioned. And if I
> notice anything else that may help you to reproduce the problem, I will
> let you know.
> 

This would certainly be very appreciated.

 
--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support

Re: Moving chapter nodes

Philippe Nobili wrote:
> Hussein Shafie wrote:
>> We consider that this operation is seldom needed, otherwise we would
>> have implemented a specific command to perform it.
>>   
> 
> Just for your information, we perform this operation very frequently.
> 

We'll eventually implement a command performing this operation.

> It's a common situation in our case not to know in advance which parts
> (sections/chapters/...) of a document will eventually be shared.
> 
> Another similar thing we often do (we use the same procedure) is turning
> chapters into sections and conversely, appendix into chapters, etc.... 
> The rationale is the same (== not knowing in advance how documents parts
> will be organized and shared among documents).

Please select the "Document structure"  item in the View menu and then
use the Promote and Demote commands in order to perform these tasks
(chapter to section and the other way round, but not chapter to appendix).
See http://www.xmlmind.com/xmleditor/_distrib/doc/docbook/docbook_menu.html

> 
> For all these cases, the copy and paste of children works fine, but this
> is not always easy to guess...; specific commands might be useful.
> 

 
--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support

Re: fine-tuning XHTML ouput

Niels Grundtvig Nielsen wrote:
> I do realise the conversion/output options are provided by way of example, and indeed that it's not
difficult to open the xhtml source in an editor afterwards ... but I was wondering if there was any simple
way of persuading the conversion to leave references to svg graphics untouched. 

It's certainly possible to have the XHTML/HTML generated by "Convert
Document" menu reference the SVG files specified in the XML source.

However for that you need to modify the following process commands:

* DocBook 4: docb.convertStep1 found in
XXE_install_dir/addon/config/docbook/xslMenu.incl.

* DocBook 5: docb.convertStep1 found in
XXE_install_dir/addon/config/docbook5/xslMenu.incl.

---
        <resources match=".+\.(png|jpg|jpeg|gif)"
                   copyTo="resources" />
---

must be replaced:

---
        <resources match=".+\.(png|jpg|jpeg|gif|svg|svgz)"
                   copyTo="resources" />
---

(This reads: if the document being converted references a resource
having a png, jpg, jpeg, gif, svg or svgz filename extension, simply
copy it to the resources/ directory (and hence, do not convert it to
another format.)

* DITA: dita.toXHTML, dita.toXHTML1, etc, found in
XXE_install_dir/addon/config/dita/xslMenu.incl.

---
        <argument>-images</argument>
        <argument>images/*.{png,jpg,jpeg,gif}</argument>
---

must be replaced by:

---
        <argument>-images</argument>
        <argument>images/*.{png,jpg,jpeg,gif,svg,svgz}</argument>
---

> If I've made the choice to deliver referenced graphics as svg, it's a bit surprising that the tool then
knows better and generates png versions.
> 

It's not that clear. One may use SVG files[*] and still want the
generated XHTML/HTML pages to be compatible with a maximum number of web
browsers.

FYI, even latest Internet Explorer 8 still does not support SVG
natively[**].

---
[*] Simply because she/he authored her/his graphics this way, or because
SVG files give great results when the same document is converted to PDF
or PostScript.

[**] On 1 January 2009, Adobe Systems discontinued the support for its
SVG Viewer plug-in; so you are somewhat stuck with IE.

 
--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support

Re: fine-tuning XHTML ouput

> [*] Simply because she/he authored her/his graphics this way, or because SVG files give great results
when the same document is converted to PDF or PostScript.

Indeed! and because the graphics I work with tend to have a lot of text in; it's often handy to be able to use the
browser Search function

[**] On 1 January 2009, Adobe Systems discontinued the support for its SVG Viewer plug-in; so you are
somewhat stuck with IE.

Thanks for the reminder; Firefox had protected me from that particular problem, but now I'll need to reconsider.

 
--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support

Support for cross-referencing within a modular document?

I am working on a docbook 5 modular users guide (each chapter in 
separate file) with html, and I am now sort of stuck on the 
cross-referencing matter. For a single-file document the xref elements 
are very convenient to use, with xxm keeping track of available 
linkends. A quite extensive web research on how to work with 
cross-referencing in modular documents has pointed me to the conclusion 
that one should use olinks (or links with xml:href attributes) with 
target database(s) to get things right. The whole olink machinery seems 
quite complex, and perhaps a bit overkill for modular document 
cross-referencing (is seems more designed for cross referencing within 
collections of books).

Before spending a lot more time on this I would like to get some input 
from other users.

* What are best practices for cross referencing within a modular document?

* Are there any good tutorial style web resources on modular documents 
and cross-referencing (using xxe)?

* Is olinking with target databases supported by xxe, and if so, to what 
extent?

/Magnus

--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support

MathML and xhtml

It seems that also when producing xhtml any mathml content is 
transformed to png images. Some browsers (Firefox etc.) does a very good 
(better than this png output, in my opinion) in rendering MathML. Is 
there any way to make xxe pass the mathml elements "as is" to the xhtml 
output?

I also wonder if it is possible to tweak the png generation. To be 
precise, many equations are rendered so small that indices and other 
small typographic elements are difficult to read.

/Magnus

--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support

Re: Support for cross-referencing within a modular document?

Magnus Gäfvert wrote:
> 
> I am working on a docbook 5 modular users guide (each chapter in
> separate file) with html, and I am now sort of stuck on the
> cross-referencing matter. For a single-file document the xref elements
> are very convenient to use, with xxm keeping track of available
> linkends. A quite extensive web research on how to work with
> cross-referencing in modular documents has pointed me to the conclusion
> that one should use olinks (or links with xml:href attributes) with
> target database(s) to get things right. The whole olink machinery seems
> quite complex, and perhaps a bit overkill for modular document
> cross-referencing (is seems more designed for cross referencing within
> collections of books).
> 
> Before spending a lot more time on this I would like to get some input
> from other users.
> 
> * What are best practices for cross referencing within a modular document?
> 

Do *not* use olinks. olinks should be reserved to linking deliverables
which are part of the same set of documents. This is very different from
a modular document.

Use xref and link elements and type the linkend attribute as if the
document module was part of the master document. XXE currently provides
no assistance in doing that. You are currently forced to know the link
targets  ``by heart''.

(This is what we do for our own documents.)

> * Are there any good tutorial style web resources on modular documents
> and cross-referencing (using xxe)?

No.

> * Is olinking with target databases supported by xxe, and if so, to what
> extent?

Yes and no.

Yes. XXE is an XML editor and as such, supports olinks as any other
element. Our own document set makes use of olinks. You can download the
sources to our own document set from here:
http://www.xmlmind.net/xmleditor/_download/xxe-docsrc-4_5_1.zip

No. XXE will not help you in quickly creating olinks.

The target database stuff is purely a DocBook XSL stylesheets artifact
and thus, is not related to XXE. An olink is basically the identifier of
a document + optionally an ID found in this document.

--> Now, the good news. XXE v4.6 will have a "Link tool". This new tool
should solve the following problem: quickly and easily create links in
modular documents.

This new tool will use ``master documents'' as ``link contexts''.

A master document is:

* Any XML document making use of XIncludes.

* OR A DITA map or bookmap.

* OR A synthetic map, mapping unique identifiers to DocBook documents.
This should allow to quickly insert olinks.

(Of course you'll have to use the same identifiers in the target database.)

 
--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support