I explain at the bottom of this email – let me hear if you also need
demo documents.
On 26.02.2024 10:40 Hussein Shafie:
2) As for the last variant, namely to flatten the ebook to a single
file: Why can't you instead fix the XHTML preview command?
Because we don't understand what is the problem with the XHTML Preview
command.
Here we use the XHTML Preview command all the time and it works great
for us. Not to check links but to see how the page would look in the
browser with our "corporate" CSS stylesheet. (Hence the name
"Preview") See "Preview Settings",
https://www.xmlmind.com/xmleditor/_distrib/doc/xhtml/menu.html#previewSettings
Please send us a sample HTML page containing links, xincluding
sub-documents and referencing external images and please explain what
you expect the XHTML Preview command to do.
We have nothing against improving the XHTML Preview command but if you
use case is too specific or if your RFE is best implemented using
other means (e.g. implement an actual link checker orthogonal to the
XHTML Preview command), we will not implement your RFE.
As I described initially, in our case XHTML preview fails to create a
working single document, the problem being that many URLs fails to be
converted to URLs that function in the flattened document. This goes
for links at least (but right now aI forgot if it also goes for image
URLs).
Sorry but we don't understand this.
The XHTML Preview function has two «modes»:
First mode: For documents without (X)includes, it simply directs the
file to the Web browser. For mode 1 previews, there are no problems
that I am aware of, and of course it is a great way to preview a file
with your "corporate" CSS files on an external Web server.
Second mode: For documents with (X)includes, the process is more
complicated: the document plus all its includes are glued together into
a single file. However, this process takes place inside
<file:///private/var/foo> – that is: not inside the folder where the
main document file is located. And this «move» into /private directory,
has — in itself — several consequences. (There would be less trouble if
the preview file had been created inside the folder where the working
file is stored.)
Our issues (and thus, the problems I describe below) are only related to
the second mode:
1) One of the consequences is that external CSS becomes unavailable to
the preview if — as we do — one embeds CSS via <style>@import
"url/to/file.css"</style>. Why? Simply because the XHTML Preview command
does not update "url/to/file.css" to something that works when the
previewed files is located inside the "/private" directory.
(Workaround: Use <link rel="stylesheet" href="url/to/file.css"> instead
— I just discovered that the XHTML Preview command **does** convert
href="url/to/file.css" to href="absolute/url/to/file.css".)
2) Another consequence is for ordinary links – that is @href inside <a>.
Are such link URLs converted to absolute URLs? Unfortunately not.
Consider the following compound document:
*: motherDocument.xht
*.*: contents.xht (xincluded into mother document)
*.*: chapt1.xht. (xincluded into mother document)
*.*: chapt2.xht. (xincluded into mother document)
Inside the 'contents.xhtml' file, there is a table of contents, with
links to locations in the various chapter files etc.
Thus, in the 'contents.xht' file, we find for instance this:
<a href="chapt1.xht#location-1">Chapter 1</a>
<a href="chapt2.xht#location-2">Chapter 2</a>
Because XHTML Preview is supposed to "flatten" the document into a
single document, one would expect that the above two links, would become
converted into the following:
<a href="#location-1">Chapter 1</a>
<a href="#location-2">Chapter 2</a>
If this had happened, then I would have been able to use the link
validation tool to check for broken links.
But this does not happen. In fact, nothing happens. The URLs are left
unchanged. Hence, ordinary links in the preview document points to
locations outside the document ...
I hope this was better explained. And that you can solve this issue
pretty easily.
Leif Halvard Silli
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
