Re: How to check links in compound documents?

Leif Halvard Silli <[email protected]> Tue, 12 Mar 2024 00:23:54 +0100
Newsgroups gmane.editors.xxe.general
Message-ID <[email protected]>
I include a simple test case in this message - see the 3 attached file. 
The 'master' file embeds/includes the other two files. If you preview 
the master file via XHTML Preview, you should experience the error that 
I described.

Leif Halvard Silli

Den 12.03.2024 00:00, skreiv Leif Halvard Silli:
> 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
include.html (text/html, 267 B)
<!DOCTYPE html>
<article id="ide" lang="en-GB" xmlns="http://www.w3.org/1999/xhtml"><h1 id="otherElement" lang="en">Table of Contents</h1><ul>
  <li><a href="include.xhtml#includedLocation">Link to location in the (other) x-included element</a></li>
 </ul></article>
include.xhtml (application/xhtml+xml, 189 B) - not displayed
master.xhtml (application/xhtml+xml, 333 B) - not displayed