Thank you. We used your simple test case to understand the issue you
describe.
I'm sorry but we will not implement the kind of link conversion you
expect "XHTML|Preview" to do.
"XHTML|Preview"
(https://www.xmlmind.com/xmleditor/_distrib/doc/xhtml/menu.html#preview)
is deemed to work sufficiently well for its designed task: see how the
page would look in the browser with one's "corporate" CSS stylesheet.
However, we'll seriously consider adding a external link checker to a
future version of XXE.
This built-in external link checker would work whatever the type
document being opened (XHTML, DITA, DocBook, etc).
It would check absolute and as well as relative links and ideally would
support fragments (e.g. foo.html#bar).
It would not be turned on by default (e.g. automatic check when opening
or saving the document) as checking external links is a time consuming
task; even more if fragments are supported.
On 3/12/24 00:23, Leif Halvard Silli wrote:
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.
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
