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:
* 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.
* 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.
* (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:
* href="русский%20файл.dita"
* But if I use the file system based file chooser to do the same thing,
the result becomes completely unreadable:
*
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"
* 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.
--
leif halvard silli
--
XMLmind XML Editor Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
