On 11/21/2017 02:00 PM, Leif Halvard Silli wrote:
I have used DITA quite much lately, and I too have some comments about
the way SPACE is handled in URLs. Like Don Mankewich, I am not satisfied
with the behavior. And, in addition, I believe I have found a bug - or
at least an inconsistency. See below.
On 15 Nov 2017, at 9:53, Hussein Shafie wrote:
On 11/14/2017 11:41 PM, Don Mankewich wrote:
I’m using the personal edition of the XMLMind DITA editor for
evaluation
purposes and I was confounded by the inability to have a
relative file
path with spaces in the folder name until I realised that the
space had
to be represented by a ‘%20’.
DITA is not file based, but URL based. A file path like "..\My
Images\logo.png" must be specified as "../My%20Images/logo.png".
This should not be a problem unless you type the path "by hand",
which is not recommended. See below.
Right. But as I say below, it is still a display issue for the user
(after the URL has been added). For instance inside the map/bookmap
document, the file name become difficult to read because the %20 is
displayed to the user.
And also, if the file name contains non-ASCII characters, then XMLmind
will also convert the non-ASCII letters to percentage encoding - but
only if you use the "normal" file chooser. If you use the URL-based file
chooser, the non-ASCII letters are not converted to percentage encoding.
See more below.
Further more, I disagree about your “by hand” view in this case. Again,
if you use the URL chooser, you have to type the file name yourself
anyway (if you are creating a new file) and then you must (eventually)
add the %20 by hand. At least the way it currently works.
This isn’t particularly intuitive for a
near-WYSIWYG editor so can the ‘set link target’ attribute panel
be made
to accept spaces in the file path?
Sorry but space characters are not allowed in URLs.
But XMLmind should handle that problem automatically - not involving the
user in that problem. It should display a space to the user while using
the %20 code in the background/the code. See more below.
XMLmind effect on my coding behavior:
1.
The current behavior of XMLmind editor has made me more or less stop
using spaces in file names. Or more precisesly, I have switched from
using “normal” SPACE to, instead, be using “NO-BREAK SPACE”. The
advantage of this is that the space is displayed like a gray dot.
2.
The way XMLmind editor displays the NO-BREAK SPACE in URLs gives a
hint about how XMLmind ought to handle the SPACE character in URLs
as well: To the user, it should display white space, while in the
code it should represent the character as “%20”.
Please note that:
*
The issue is not just the /adding/ of the file/URL but also the
human /reading/ of the URL - when it has been added:
o When I add a new file to a DITA map or bookmap file, I tend to
come up with a clever name in the form of a combination of
words. After the file has been added, the file name is visible
to the user in the map file. However, due to the spaces between
the words, the URL becomes very difficult to read, for user’s
eye. Why? Because there is a %20 between each word. Of course,
one may use NO-BREAK SPACE instead. But the effect of this is
that this also affect the way the file names appear - or is
represented - in the file system. For insteance, in the file
systemer I must remember to add a NO-BREAK SPACE when I search
for the file name.
*
I think there are two issues here: One issue is what is displayed to
the user inside the map or bookmap document - the %20 code should,
vissualy, be replaced by a normal space character. The other issue
is inside the URL-based file chooser and as well inside the
interface for editing the file URL - it /might/ be OK to have to
type %20 in this context, allthough I think I would prefer to not
have to do so.
As for inconsistencies:
*
While linking a file to the map document, XMLmind performs a check
of whether or not one adds a valid URL. Thus is cries out if you try
to add a SPACE. This basically is not possible.
o This is an issue if you use XMLmind’s URL-based file chooser
(which one can enable via the second menu item in the File
menu): If you need create and add a totally new file called
"Lorem Ipsum.dita" you may, in the file chooer type "Lorem
Ipsum.dita" as file name. Then you are told to add %20:
"Lorem%20Ipsum.dita".
*
However, the inconsistancy, is that once you /have/ added
"Lorem%Ipsusm.dita" to your map file (as described above), you can,
in fact, get rid of the space character by choosing ”Edit topic …”
(in the contextual menu, when you select the <topicref> element): If
you /now/ delete the "%20" and replace with a ”normal” SPACE
character - " ", XMLmind will in fact not complain. That is:
XMLmind’s conformance checker does not cry out in any way.
o (I also checked what XMLmind editor will, in such a case, output
if you convert your bookmap file to a multipage XHTML, and it
turns out that it handles it just fine - I think there was no
difference between whether %20 was added or not.)
*
My wish is that XMLmind editor will represent the spaces as "%20" in
the code, but that it will display them as spaces to the user.
Another, related inconsistency and bug:
* When adding a new file, using the URL chooser, I may give file a
Russian name - such as “Russian file" in Russian:
”русский%20фаил.dita". I then have to type the SPACE as %20. The
result becomes this:
o href="русский%20файл.dita"
This is indeed a (not so harmless) bug. It should be
href="%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB.dita".
* But if I use the file system based file chooser to do the same
thing, the result becomes completely unreadable:
o
href="%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB.dita"
This is the correct behavior.
* The URL standard does not require non-ASCII to be represented as
percentage encoding. It only requires that URL parsers convert the
code, internally, to percentage encoding before interpreting the
URL. So this behavior is both unneccessary and not useful to the
user. In fact, it probably causes user to not include non-ASCII in
their URLs/file names.
I'm sorry but we cannot afford to spend countless hours of work
switching XXE code base from "old" URLs to "new" IRIs
(https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier).
Anyway, the vast majority of our users do not work with remote files at
all. The behavior of XXE when you work with local files is deemed
acceptable, even when the file name contain space or non-ASCII characters.
Example: right-clicking <xref
href="%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB.dita">
and selecting "Follow Link" from the popup menu opens a document tab
having a "русский фаил.dita" caption.
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
