On 2/6/2020 2:47 AM, Hussein Shafie wrote:
Sorry but we have never received your initial post
That must be because I included a zip file as an attachment that had a
minimal working example. I've put it here:
https://drive.google.com/file/d/1QyuP5LwJheEr-jsD_zQqXvCAc6bcBmpJ/view?usp=sharing.
("On 2/5/2020 11:11 AM, H. Andrew Black wrote:").
I'm not sure to be able to reproduce this issue on any of our computers.
Which operating system/file system (name, version) sometimes uses NFD
and sometimes NFC to represent its file names? Seems to be a weird
idea inevitably leading to a lot of troubles (not just with XXE).
Mine is Windows 10. A user is on some form of Linux. He just wrote to
me the following:
"The decomposed (NFD) form is preferred for our work, because High tone
is not a part of a vowel, but rather something that goes with it. This
is reflected in our virtual keyboards, and allows searching for high
tone, irrespective of vowel ... This is different from the normal NFC
case, like French é, which is it's own vowel, not e and high tone, etc."
So for him, he always uses NFD at least internally in his programs (and
maybe in his text files so he can do searches). The file name at issue
was automatically generated by a program called Praat
(http://www.fon.hum.uva.nl/praat/) based on the information he keyed
into it. That is, Praat created the file name using NFD and his Linux
file system accepted it without converting it to NFC. (In the NFD
sample file in the zip file above, I copied just a small portion of the
Praat-generated file name and renamed my PNG file to use it.)
So, what to do? I see at least two possibilities:
1. Our user finds a way to convert his *file names* to use NFC and not
NFD. Then they always load correctly in XXE. If, however, he needs to
be able to do searches on file names where the tone (NFD) is crucial,
then that will be a problem for him. If, instead, he only needs to
search on the *contents* of files, then converting file names to NFD
should work well for him (assuming he can figure out how to do that).
2. See if XXE can keep the NFD/NFC distinction when getting the file
name. One possibility might be at
https://stackoverflow.com/questions/43380362/java-differentiate-between-files-in-unicode-nfc-and-nfd.
Thanks,
--Andy
---
PS: I found my info about NFD/NFC here:
https://en.wikipedia.org/wiki/Unicode_equivalence
On 2/5/20 9:00 PM, H. Andrew Black wrote:
We just discovered that the acute i in the file name that works is
NFC (composed) while the acute i in the one that does not work is NFD
(decomposed). So it looks like the Choose File option converts the
NFD acute i to NFC. When XXE tries to find the file using the URI
with NFC, it cannot find the file that has NFD. Does this make sense?
Yes. Totally.
--Andy
On 2/5/2020 11:11 AM, H. Andrew Black wrote:
Hi, Hussein.
Using XXE version 9.2.0 (or earlier versions, too, like 8.3.0 and
7.5.0), we've noticed an odd thing with graphic image file names. In
the Attributes Editor tool, we use the Choose File option to find
the image file. Some file names that contain an acute i (í) display
correctly and some do not. The ones that do not give the red
message of "Cannot display image: (file location) (The system cannot
find the file specified)." In both cases, the acute i is converted
to %C3%AD which is the UTF-8 code for an acute i.
I'm attaching a minimal working example of this problem for a
DocBook section file. Unzip it and load the XML file into XXE and,
hopefully, you'll see that the first image renders fine but the
second does not.
Is there something we're doing incorrectly with the second file?
Thanks,
--Andy
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
https://www.xmlmind.com/mailman/listinfo/xmleditor-support
