Linked png in QtHelp file
-
For many years now our Qt-dependent software has provided help files. Our distribution includes .qhc and .qch files. The HTML components included anchor parts like "<a href='sample_dialog_1.html'>Sample Dialog</a>" whereby a user could link to a separate relevant documentation page. We also sometimes include an anchor like "<a href="images/simple_dialog_2.png'>Simple Dialog</a>" when the referenced window/dialog to be shown is simple and not requiring text to explain.
This used to work under Qt4. But now, with Qt5, clicking on the link to a PNG file results in text showing the content of the png file and not the image itself. Note that embedded images (e.g., "<img src='images/simple_dialog_3.png'/>") still work fine. Can anyone offer a reason why this ability disappeared with Qt5 and any remedy, apart from wrapping the image files in thin html? Thanks in advance for any guidance.
-
Hi and welcome to devnet,
You have to be more specific, which version of Qt 5 are you talking about ?
-
@SGaist The symptom of mishandling png files actually occurs both in qt 5.6.0 and 5.6.2. Do you believe that QtHelp files correctly handle png file in anchors in any version of Qt5?
-
Your current version of QtHelp is likely using QtWebKit as backend which as been deprecated and was removed in Qt 5.6. More recent version is using the basic QTextBrowser class which has less features.
You can test with Qt 5.5.X
-
We display our help files (via .qhc, .qch) by running Assistant with arguments like "--collectionFile ... manual.qhc". It is not an application that we build that actually does the display; rather it is Qt's Assistant.
-
Update : sorry missed SGaist post. This info is redundant :)
Yes but I think it was also changed.
Let me find old 5.5 and check :)
Maybe i remember wrong.Nope. was webkit before
So it might be related going from webkit to Text Browser?
-
Let me see if I understand where this is going. Are you saying that the move to QTextBrowser is what broke the ability to handle HTML in all the ways a browser would? That would include handling "<a href='...png'....". So, I'd have to revert from 5.6 back to 5.5; or wait for a fix to QTextBrowser?
-
@gegorbet
Hi, im not saying its that. You should test it.Its just that TextBrowser is not a full browser as webkit was. (AT ALL)
If using the TextBrowser is the reason for it then you should
look into find other way to make it work for Text Browser. ( other html code)
Or just use 5.5 if that is an option.
Webkit is deprecated and unless TextBrowser is supposed to handle png the same way,
its very unlikely there will ever be a fix.
-
@mrjj Good to know. I am building 5.5.1 to see if webkit fixes my problem. If so and if - as you say - there is unlikely to be a fix forthcoming in QTextBrowser; then at least I'll know the situation. I would be inclined to wrap all my linked PNG files in thin HTML rather than be tied to a deprecated class.
-
No joy. Built with 5.5.1 (WebKit), Assistant still displays PNG files as their content, not an image. Any other ideas of where to look?
-
I'll have to back off my previous statement. The 5.5.1 I built has an Assistant binary which - according to the About - uses TextBrowser. So, I have not demonstrated that WebKit won't display png's correctly. What arguments do I add to the configure to insure Assistant builds with WebKit?
How do I attach an image to a post?
-
What OS are you on ?
-
@SGaist CentOS 6.7
-
After a long set of sessions building Qt 5.5.1 with arguments I thought might link in WebKit, I arrived at a 5.5.1 assistant which its About dialog says still uses TextBrowser. Lots of Googling with no results, so I ask here: do you know what arguments to ./configure insure Assistant uses WebKit?
-
What parameters are you passing to configure when you build Qt ?
-
@SGaist What parameters would you suggest in order to have Assistant use WebKit?
-
@mrjj My efforts to prove that the WebKit-to-TextBrowser change is what has removed the ability to directly anchor PNG files in Assistant-based help has just taken too long and not produced reliable results. Similarly, my efforts to get acknowledgement (here or in various Googled sites) that this is a known problem have been fruitless thus far.
I wrote a script that produces a thin HTML wrapper to each PNG I wish to anchor. Writing that script, applying it tor 17 anchored image files and modifying the appropriate href= values in 28 individual HTML components took much less time than I'd spent so far trying to find a Qt fix or appropriate general modification in our code.
Thank you, mrjj, for the knowledge about TextBrowser. I will likely be marking this topic as "Solved" shortly unless there are any further relevant insights brought forward.
-
Thank you for trying to verify. I had no luck either finding info regarding loss of
this feature or similar. I remembered it - as suddenly the help looked .. different.Could you for future reference paste a "used to work" html sample and
how it should look to do the correct thing with text browser?
-
@gegorbet You need to built Qt with widgets and webkit enabled in order for Assistant to also get built since it uses the webkitwidgets module.
-
@mrjj
This used to work:
<a href=“images/vhw_enh_groups.png”>vHW Enhanced Groups</a>
Now I must use:
<a href=“vhw_enh_groups.img.html”>vHW Enhanced Groups</a>
where the *.img.html file is just a rudimentary header and footer of HTML around:
<img src="images/vhw_enh_groups.png" alt="van Holde -Weischet groups dialog"/>
-
I tried one more time to build a 5.5.1 Qt where Assistant (for custom help) uses WebKit. I added "-D BROWSER_QTWEBKIT" as a configure argument. But I encountered numerous compile and link problems and never got a new Assistant built.
So, I've decided to spend no more time on this. The topic is "Solved" in the sense that it is assumed that TextBrowser will never properly handle anchored png files. In our applications help files, all anchored png have been replaced with img.html files that are thin HTML wrappers around an embedded image.
Thanks again. mrjj, for your help.
-
@gegorbet
Hi
Building webkit is often a pain. Multiple dependencies. But you gave it a good shot :)
I agree that the wrapper you made
seems the best way forward as having to compile own version
of Assistant is not optimal.
Thank you for reporting back on this matter. It will come up again :)
