https://bugs.documentfoundation.org/show_bug.cgi?id=82149
--- Comment #25 from Regina Henschel <[email protected]> --- (In reply to Maxim Monastirsky from comment #22) > So help files have links like "cmd/sc_line.png", and we mass-transform it > using xslt to "vnd.sun.star.zip:/path/to/images_<current-theme>.zip/cmd ... > and feed that to the web view. There isn't much we can do with such logic. > One possible solution is what kendy suggested in a comment in > Databases::getImagesZipFileURL: > > 280 // FIXME instead of using a general vnd.sun.star.zip:// > 281 // for imgrepos, we should have some vnd.sun.star.image:// I disagree with that as long term solution. I think, that in a long term solution the transformation should result in a html, which can be shown with every browser and does not contain any propriety protocol. That would need to rethink, whether the images need to be zipped at all. For example in my installation the zipped images_galaxy.zip has size 2478KB and the unzipped folder 1989KB. > > ... and internally this new content provider should use the normal way of > loading icons, as we do for UI elements. But the real problem is, that the images are not used directly, but via the links.txt file. This file cannot be used in the xsl transformation. My current idea is to wrap the links.txt file into a .xhp document so it can be read by the document() function in the main_transform.xsl. Perhaps use a coded form of the image-link as paragraph id. But there is nothing testing up to now. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
