After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660092 - Relative imagedata fileref not loading image in Yelp
Relative imagedata fileref not loading image in Yelp
Status: RESOLVED OBSOLETE
Product: yelp
Classification: Applications
Component: DocBook
3.1.x
Other Linux
: Normal major
: ---
Assigned To: Yelp maintainers
Yelp maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-26 04:11 UTC by Jonathan
Modified: 2018-05-22 12:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonathan 2011-09-26 04:11:59 UTC
Greetings! I noticed that in newer versions of Yelp, using a relative fileref path no longer loads an image in Yelp.  For example, I have a Docbook XML document with lots of images.  I've included an example below:

<mediaobject>
  <imageobject>
    <imagedata fileref="../figures/logo_badge.png"/>
    <caption/>
  </imageobject>
</mediaobject>

The /figures/ folder is shared between many different XML files, so it's in a parent folder, as you can see by the "../".  In older versions of Yelp (such as version 2.3) the above syntax loads images just fine.  In version 3.1, it just shows a small broken image.

Thanks!
-Jonathan
Comment 1 Jonathan 2011-09-26 04:37:25 UTC
If I copy the /figures/ folder into the same folder that the XML file is in, and change the fileref="figures/logo_badge.png", everything works fine.  But that would require me to copy the /figures/ folder for every language, which is not desired:

/C/figures/
/es/figures/
/fr/figures/

All the figures are identical, regardless of language, which is why I would prefer the following folder structure:

/C/
/es/
/fr/
/figures/

Also, If I change the fileref="/usr/share/gnome/help/openshot/figures/logo_badge.png", that works as well.  Of course, relative images would be preferred.

So, it seems like the problem is the "../" in the fileref path.  It used to work, and now it doesn't.  I'm just assuming this is a bug.  Please let me know if I can help test anything.  Thanks!
Comment 2 Shaun McCance 2011-09-26 14:21:57 UTC
Confirmed. This happens because Yelp tricks WebKit by using a bogus URI prefix for images and other external files, then matches on that prefix in the "resource-request-starting" callback. When you use "..", WebKit normalizes the URI, stripping off the bogus prefix.

Note that Yelp 3 resolves external files based on the full document path. So you could just put the figures directory under "C" and use the relative reference "figures/logo_badge.png", and the image from C will be loaded for all languages.

That won't work in Yelp 2 though. So if you need to deploy on both GNOME 2 and GNOME 3, you can't do it. I'll try to get a fix in for 3.2.1.
Comment 3 Jeremy Bicha 2011-12-28 21:44:20 UTC
On the other hand, putting your figures in the C directory makes them easily translatable. Any other language can make its own screenshots and throw them in their language's figures' directory. So personally I think you're doing it wrong by trying to place figures outside the C directory.
Comment 4 Jonathan 2012-01-30 15:55:08 UTC
Jeremy,
That is a good point, but in my case, I have dozens of languages, and 15 MB of images per language, and because most of my images are very generic (and don't need to be translated), it would balloon the size of the documentation to 100+ MB.  If that's the way it must be done, then maybe I need to package each language's documentation separately... which would generate dozens of additional packages to maintain.

For these reasons, I still like the idea of relative images. =)  Thanks!
Comment 5 GNOME Infrastructure Team 2018-05-22 12:56:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/yelp/issues/56.