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