Yuriko N. wrote:
Let me see if I have got it correct.
There are four ways to use svg images.
1) use img tag and keep original svg image converted into png.
<p><img src="linktest.svg"/></p>
You mean <image href="linktest.svg"/> here, where "linktest.svg" is
automatically converted to PNG by XXE.
2) use img tag and keep original svg image (by "Add "svg," to the list contained in the
"Copy images to" field".)
<p><img src="linktest.svg"/></p>
3) use svg container with svgref
<p><svg-container><svgref href="media/graphic.svg"/></svg-container></p>
Let's call these 2)a) and 2)b) because they are almost the same thing.
3) use svg container with svg:svg
<p><svg-container>
<svg:svg height="64.710144" version="1.1"
viewBox="0 0 104.28986 51.768115" width="130.36232"
xmlns:svg="http://www.w3.org/2000/svg";>
...
</svg:svg>
</svg-container></p>
Assuming that the above classification of four types is correct, I have two
questions.
100% correct.
Q1:
For above 2) and 3) expressions, image is kept in a separate SVG file and
referenced from html.
Then I think for both 2) and 3) results, the text strings within the SVG images
in webhelp will be selectable
using the mouse or CNTL-A,
It is possible for 3), but it seems not possible for 2).
Is this planned feature in ditac for 2) that the text strings cannot be
selected ?
Actually, we think that string selection should be enabled not only for 3) but
for 2) as well.
No, this is not a planned feature.
Implementing this feature for use cases 2)a) and 2)b) implies:
automatically embedding in the generated HTML page the SVG file
referenced by the means of <image href=""/> or <svgref href=""/>.
Q2:
Regarding 3), there is problem as you explained as follows.
#####
- The text content of the embedded SVG is indexed by our Web Help
Compiler (that is, appear in the "Search" pane of the generated Web
Help). This is a BUG and should not happen. SVG files are supposed
contain to images (MIME type=image/svg+xml), not prose.
#####
When user clicks the search button to search for a text string contained in SVG
images,
the corresponding text strings within the svg image disappears. It appears
again when I clear the search input.
I assume this is part of the BUG that you mentioned.
Yes, this faulty behavior happens indeed. This is a side effect of the
*real* *bug*.
I'm sorry if I didn't make myself clear. The real bug is that we
currently index the words contained in embedded SVG graphics. This
should not happen.
We plan to fix this bug in the near future by *removing* the ability to
index words found inside something like:
<svg-container>
<svg:svg height="64.710144" version="1.1"
viewBox="0 0 104.28986 51.768115" width="130.36232"
xmlns:svg="http://www.w3.org/2000/svg";>
...
</svg:svg>
</svg-container>
Will this problem be solved in your next release?
If text string cannot be selected when using 2), then we want to recommend the
use of 3) after the problem is solved.
No offense intended, but we don't agree with you when you say that the
words contained in SVG graphics whether embedded or referenced should be
indexed.
Why that? Because, in our opinion, this feature is not really useful.
The words found in SVG graphics are almost always found nearby these SVG
graphics, I mean, in the prose describing these SVG graphics.
Example:
http://www.xmlmind.com/ditac/_distrib/doc/manual/webhelp/pageHeaderFooter.html
SVG graphics "Figure 4-2. Layout of a header" contain "words"
"header-left-width", "header-center-width", etc, which are described in
the prose surrounding these graphics. Please use "Search" to search for
"header-left-width" and you'll see by yourself that the SVG graphics
"Figure 4-2. Layout of a header" is easily found this way.
--> However we are not stubborn, please give us convincing practical
cases where indexing words contained in SVG graphics is really useful.
If you can do that, we'll not remove indexing in embedded SVG graphics
and we'll also try to fix the bug of the "disappearing highlighted words".
If you cannot do that, please remember that our Web Help Compiler is
free, open source, software and that you can easily modify it yourself:
http://www.xmlmind.com/ditac/whc.shtml
Also, we find that height/width attribute use with img tag do not work
correctly for IE and Chrome (OK with firefox) anyway.
Thank you for the information.
Please note IE is no longer really supported by Microsoft. This Web
browser has been superseded by Edge.
Please also note that all the software we write is no longer tested
against IE, no matter the version of IE. (We basically rely on jQuery in
the case of IE 9+.)
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
