blocker encoding bug breaks XML compliance
99 views
Skip to first unread message
Garret Wilson
Nov 18, 2015, 1:06:35 PM11/18/15
to bluegriffon
I'm creating documentation in XHTML5 on how to use... XHTML5. I want to show what the XML header should look like so I go to the source code and enter the following:
(I have to go into the source code to do this, because BlueGriffon apparently has no way to allow me to add a <pre> inside a <figure> using WYSIWYG interface. But that is another matter.)
I go back into the WYSIWYG interface and enter:
Unfortunately BlueGriffon does not property encode the < and > symbols, so the source code remains:
What it should show in the source is something like this:
Perhaps BlueGriffon thinks this is a processing instruction. But it doesn't matter; if I type the characters in the WYSIWYG interface, they should be properly encoded.
This document breaks compliance; the XML processor will issue a fatal error that an illegal processing instruction target has been encountered.
I consider this bug a blocker, as it produces XML documents that are not well-formed.
<figure><pre><code></code></pre></figure>
(I have to go into the source code to do this, because BlueGriffon apparently has no way to allow me to add a <pre> inside a <figure> using WYSIWYG interface. But that is another matter.)
I go back into the WYSIWYG interface and enter:
<?xml version="1.0" encoding="utf-8"?>
Unfortunately BlueGriffon does not property encode the < and > symbols, so the source code remains:
<figure>
<pre><code><?xml version="1.0" encoding="utf-8"?></code></pre>
</figure>
<pre><code><?xml version="1.0" encoding="utf-8"?></code></pre>
</figure>
What it should show in the source is something like this:
<figure>
<pre><code><?xml version="1.0" encoding="utf-8"?></code></pre>
</figure>
<pre><code><?xml version="1.0" encoding="utf-8"?></code></pre>
</figure>
Perhaps BlueGriffon thinks this is a processing instruction. But it doesn't matter; if I type the characters in the WYSIWYG interface, they should be properly encoded.
This document breaks compliance; the XML processor will issue a fatal error that an illegal processing instruction target has been encountered.
I consider this bug a blocker, as it produces XML documents that are not well-formed.
Message has been deleted
Garret Wilson
Nov 25, 2015, 11:03:13 AM11/25/15
to bluegriffon
This issue is completely a blocker. It means I'll have to find a BlueGriffon alternative if this bug doesn't get fixed.
I enter something like the following in the source code:
<figure><code><pre>
new ArrayList<>();
</pre></code></figure>
I switch back to WYSIWYG mode, and I see the following, just like I expect:
But when I save the file, BlueGriffon saves the brackets as <> instead of <>.
This is incorrect. This is not well-formed XML. This breaks the file. This is a blocker issue.
I enter something like the following in the source code:
<figure><code><pre>
new ArrayList<>();
</pre></code></figure>
I switch back to WYSIWYG mode, and I see the following, just like I expect:
new ArrayList<>();
But when I save the file, BlueGriffon saves the brackets as <> instead of <>.
This is incorrect. This is not well-formed XML. This breaks the file. This is a blocker issue.
Garret Wilson
Dec 3, 2015, 10:53:02 AM12/3/15
to bluegriffon
After some more investigation, it has nothing to do with <figure>. It has to do with <pre><code>.
Oddly if I use <p><code> the bug doesn't show up. If I use just <pre> the bug doesn't show up. Only if I use <pre><code> does the bug appear.
Oddly if I use <p><code> the bug doesn't show up. If I use just <pre> the bug doesn't show up. Only if I use <pre><code> does the bug appear.
Dr. Bill
Dec 12, 2015, 5:15:35 AM12/12/15
to bluegriffon
I pasted the your source code between the <body></body> tags of an otherwise empty page. When I switched to WYSIWYG, it displayed exactly as your WYSIWYG displayed.
When I saved the file, < and > were preserved. BlueGriffon behaved as it should, not as it did for you. The file is attached, exactly as BlueGriffon saved it.
I'm running BlueGriffon 1.8, build 10151013154450, under Mac OS 10.11.1.
Perhaps something in your context is causing BlueGriffon to misinterpret the angle tags, or perhaps it's an issue with copy and paste. I have noticed that when I'm in WYSIWYG mode and copy code that contains < or > symbols, BlueGriffon converts them to the ASCII < and > characters. If I paste the same code in Source mode, the characters are NOT converted back to symbols. I appreciate that as a feature rather than a bug--it's very handy when I'm moving source code in and out of web pages--but it's a tricky feature!
This issue affects me as well, so I hope you nail down a consistent behavior. Good luck, and please post whatever else you find.
Garret Wilson
Dec 12, 2015, 11:22:23 AM12/12/15
to bluegriffon
Dr. Bill, I think you missed two things: 1) I'm using XHTML5, not HTML5; and 2) as I mentioned later in the thread, the one post indicating <code><pre> was a typo. In fact the sequence showing the error is <pre><code>, as I indicated in the first message in this thread and in the one you replied to. Somehow you managed to pick the post with the typo. :)
Create an XHTML5 document with the wizard. You don't even need the <figure>. Just enter the following in the source mode, switch to WYSIWYG mode, and save:
You'll get the erroneous file I've attached. You won't even be able to load it back into BlueGriffon!
Please verify you were able to reproduce my findings.
Create an XHTML5 document with the wizard. You don't even need the <figure>. Just enter the following in the source mode, switch to WYSIWYG mode, and save:
<pre><code>
new ArrayList<>();
</code></pre>
new ArrayList<>();
</code></pre>
You'll get the erroneous file I've attached. You won't even be able to load it back into BlueGriffon!
Please verify you were able to reproduce my findings.
Reply all
Reply to author
Forward
0 new messages