Re: How to check links in compound documents?

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
[email protected]
http://www.xmlmind.com/mailman/listinfo/xmleditor-support