I'm struggling with the PDF images. My HTML output looks just fine. But if I create a PDF the images are hidden. What am I doing wrong?
Thats an example:
<figurexml:id="bug.menu"><title>Menüleiste im Modul <emphasis>Bug-Tracker</emphasis></title><mediaobject><imageobject><imagedatafileref="bug_menu.png"width="16cm"/></imageobject></mediaobject></figure>
Here is my output:
daps --debug -d DC-SynDesk pdf
Using MAIN file /srv/www/htdocs/daps/koesterf/xml/SynDesk.xml
---------------
DOC_DIR: /srv/www/htdocs/daps/koesterf
BUILD_DIR: /srv/www/htdocs/daps/koesterf/build
DAPSROOT: /usr/share/daps
DOCCONF: /srv/www/htdocs/daps/koesterf/DC-SynDesk
BOOK: SynDesk
STYLEROOT: /usr/share/xml/docbook/stylesheet/daps2013
FALLBACK_STYLEROOT:
EPUB_CSS:
HTML_CSS:
PDF FORMATTER: fop
FORMATTER WRAPPER: /usr/share/daps/libexec/daps-fop
FORMATTER CONFIG:
MAKECMD: /usr/bin/make -f /usr/share/daps/make/selector.mk --debug=b -j2 pdf
XSLTPROCESSOR: /usr/bin/xsltproc
XML_CATALOG_FILES: /etc/xml/catalog
DAPS VERSION: 2.1.3
DB-STYLESHEET-VERS: 1.78.1
---------------
GNU Make 4.0
Built for x86_64-unknown-linux-gnu
Copyright (C) 1988-2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating goal targets....
File 'pdf' does not exist.
File 'list-images-multisrc' does not exist.
Must remake target 'list-images-multisrc'.
Successfully remade target file 'list-images-multisrc'.
File 'list-images-missing' does not exist.
Must remake target 'list-images-missing'.
The following images are missing:
bug/all-users bug/application-pdf bug/bug-tracker-infoarea bug/bug_action_area bug/bug_button_action bug/bug_edit_action bug/bug_message_save bug/bug_platform bug/bug_platform_delete bug/bug_platform_overview bug/bug_plattform bug/bug_report_data bug/bug_report_data2 bug/bug_report_head bug/bug_software_component_filter bug/bug_software_component_overview bug/bug_software_components bug/bug_software_delete bug/bug_software_report_page1 bug/bug_software_report_page2 bug/bug_tracker_filter bug/bug_tracker_git_icon bug/bug_tracker_overview bug/bug_tracker_result bug/document-edit bug/remote-user bug/trash-empty
File 'pdf' does not exist.
Must remake target 'pdf'.
PDF book built with REMARKS=0, DRAFT=no and META=0:
/srv/www/htdocs/daps/koesterf/build/SynDesk/SynDesk_color_de.pdf
As you can see there are some missing images. But the existing ones should be in the PDF, shouldn't they?
Regards
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All images need to be located in images/src/<FORMAT>/filename.<FORMAT>
Where format is one of "png, jpg, svg, fig, dia".
This ensures that images are found automatically and can be automatically be converted into other formats, if required.
The error message above suggested that you put the images into the sub folder bugs/ - this is not supported. Also make sure that image basenames must be unique across the whole image tree - having images/src/png foo.png and images/src/svg/foo.svg is not supported.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW: If you create HTML and PDF from the same sources, you may rather want to try the following <figure> - it allows different formats and dimensions (width/height) for PDF and HTML:
<figurexml:id="bug.menu"><title>Menüleiste im Modul <emphasis>Bug-Tracker</emphasis></title><mediaobject><imageobjectrole="fo"><imagedatafileref="bug_menu.svg"width="16cm"format="SVG"/></imageobject><imageobjectrole="html"><imagedatafileref="bug_menu.png"width="16cm"format="PNG"/></imageobject></mediaobject></figure>
This would require "images/src/svg/bug_menu.svg" - DAPS will automatically create the png image required for HTML output. Of course using the same image formats for both HTML and FO (PDF) is supported, too:
thank you for your rapid response. As I mentioned above the HTML output is OK. Here can I see the correct image. In PDF there is no image.
Well, I've corrected my image paths in the whole document. Though I'm getting no errors anymore, but the images are still hidden. It doesn't matter if I use the role attribute.
SLGH07-DB02:/srv/www/htdocs/daps/koesterf # daps -vv -d DC-SynDesk pdf
Using MAIN file /srv/www/htdocs/daps/koesterf/xml/SynDesk.xml
---------------
DOC_DIR: /srv/www/htdocs/daps/koesterf
BUILD_DIR: /srv/www/htdocs/daps/koesterf/build
DAPSROOT: /usr/share/daps
DOCCONF: /srv/www/htdocs/daps/koesterf/DC-SynDesk
BOOK: SynDesk
STYLEROOT: /usr/share/xml/docbook/stylesheet/daps2013
FALLBACK_STYLEROOT:
EPUB_CSS:
HTML_CSS:
PDF FORMATTER: fop
FORMATTER WRAPPER: /usr/share/daps/libexec/daps-fop
FORMATTER CONFIG:
MAKECMD: /usr/bin/make -f /usr/share/daps/make/selector.mk -j2 -s pdf
XSLTPROCESSOR: /usr/bin/xsltproc
XML_CATALOG_FILES: /etc/xml/catalog
DAPS VERSION: 2.1.3
DB-STYLESHEET-VERS: 1.78.1
---------------
Creating fo-file...
Note: namesp. cut : stripped namespace before processing SynDesk - Anwenderhandbücher
Note: namesp. cut : processing stripped document SynDesk - Anwenderhandbücher
Making portrait pages on A4 paper (210mmx297mm)
WARNING: toc : Unknown TOC element book
WARNING: toc : Unknown TOC element book
Successfully created fo file /srv/www/htdocs/daps/koesterf/build/.tmp/SynDesk-fop_color_de.fo
Creating PDF from fo-file...
PDF book built with REMARKS=0, DRAFT=no and META=0:
/srv/www/htdocs/daps/koesterf/build/SynDesk/SynDesk_color_de.pdf
As you mentioned, I'm creating the pdf and html output from the same source.
Regards
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This ensures that all files are rebuild. If that does not solve the problem, more debugging is needed:
Have a look at the *.fo file in /srv/www/htdocs/daps/koesterf/build/.tmp and search for one of the missing images or, alternatively, fo:external-graphic. Check if the paths to the images are valid using the following command:
readlink -e <PATH>
BTW (unrelated to the problem): Looks like you are building from DocBook5 sources. If that is correct, use
Well, I've corrected my image paths in the whole document.
I think that might be the issue. You can continue to use e.g. <imagedata fileref="bug_menu.png"/> (i.e. without the path) but you have to move the image files under images/src/[format].
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That way writers do not have to remind any paths when embedding images or XML documents - the file name is all that is needed. As mentioned above, it also ensures that DAPS can automatically convert to other formats.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The DAPS structure is created the way you mentioned above. You can find the PNGs in "/srv/www/htdocs/daps/koesterf/images/src/png".
daps --force -d DC-SynDesk pdf
/srv/www/htdocs/daps/koesterf/images/src/png/all-users.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/application-pdf.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug-tracker-infoarea.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_action_area.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_button_action.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_edit_action.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_menu.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_message_save.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_platform.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_platform_delete.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_platform_overview.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_report_data.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_report_data2.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_report_head.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_software_component_filter.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_software_component_overview.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_software_components.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_software_delete.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_software_report_page1.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_software_report_page2.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_tracker_filter.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_tracker_git_icon.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_tracker_overview.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/bug_tracker_result.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/document-edit.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/remote-user.png not optimized.
/srv/www/htdocs/daps/koesterf/images/src/png/trash-empty.png not optimized.
PDF book built with REMARKS=0, DRAFT=no and META=0:
/srv/www/htdocs/daps/koesterf/build/SynDesk/SynDesk_color_de.pdf
SLGH07-DB02:/srv/www/htdocs/daps/koesterf #
I've checked the .fo file. There I found the entry for my image pointing to "/srv/www/htdocs/daps/koesterf/build/.profiled/noprofile/bug_menu.png". But in that noprofile directory is no image. So it's clear why there is no image shown in the PDF.
BTW: Thank you for your advice with the DB5 stylesheet. Where can I get it? I'm unable to find the correct RPM in my OpenSuse 13.2.
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The DocBook5 variant of the /usr/share/xml/docbook/stylesheet/daps2013 stylesheets is shipped with the suse-xsl-stylesheets package. The version shipped with openSUSE 13.2 does not have them, but you could install the version from Documentation:Tools:
sudo zypper ar -f \
http://download.opensuse.org/repositories/Documentation:/Tools/openSUSE_13.2/ \
Documentation:Tools
sudo zypper in suse-xsl-stylesheets-2.0.3
This repository also always provides the latest DAPS version for openSUSE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Creating HTML pages
warning: failed to load external entity "http://docbook.sourceforge.net/d:release/xsl-ns/d:current/d:xhtml/manifest.xsl"
That URL is definitely wrong. For some reasons, the URL contains tag names. Either it's a bug in daps and the stylesheets, or your environment is screwed up.
However, you can try something different:
Call daps-init and create an environment somewhere else (probably /tmp would be good for testing). I
$ daps-init --docdir /tmp/foo --docbook5
Build it as usual with daps
Look for some errors.
I guess, this little test should build just right. If your license or other things permit it, you can also send or attach a tarball with all of your files.
Hope this gives some hints. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Martin, can you try the suse2013-ns stylesheets instead? (The DAPS stylesheets are a thin layer over those... and the DocBook 5 version of them has at least the above bug...)
(Sorry, I hope we are not confusing you with too many instructions :/ .)
Last edit: Stefan Knorr 2015-11-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are right, that's a bug in the daps2013/ stylesheets, but that should not be the case of the error Martin encountered - they work for me regardless of that error.
Edit: I was wrong because I overlook that this error occured when generating HTML rather than PDF. I can confirm the error Martin encountered and will do further debugging. It's definetely caused by the wrong include statements and does not occur with
Martin, there is no need to do the test Thomas has asked for. Just set STYLEROOT in the DC file to /usr/share/xml/docbook/stylesheet/suse2013-ns or do not set STYLEROOT at all (in that case the Docbook stylesheets will be used). In the meantime I will try to fix the daps2013 stylesheets.
Last edit: Frank Sundermeyer 2015-11-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The bug in the daps2013/openSUSE2013 stylesheets where DocBook 4 stylesheet files were included in the DocBook 5 stylesheets has been fixed, see https://github.com/openSUSE/suse-xsl/issues/107
We will test the updates beginning of next week and will release new DAPS and suse-xsl-stylesheets versions ASAP. openSUSE/SLE packages will be available shortly after release on Documentation:Tools.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
luckily, you found already the bug and Stefan kindly offered his help. Great!
In case you have further issues I have an additional idea I would like to share with you.
It is always a bit difficult for developers to debug and reconstruct all the problems someone else has. It helps a lot to have the source code to play with. ;-)
As your documentation contains probably sensitive information that shouldn't or couldn't shared with others, I've written an "obfuscate" template some time ago. It just copies everything, except that it rewrites all text nodes to 'x'. You can find it in the daps GitHub repository, use the stylesheet daps-xslt/contrib/obfuscate.xsl.
Whenever you want to share some source code with us, use that stylesheet to transform your XML file. You can use xsltproc for this task:
Unfortunately, this is a manual task at the moment. If you have lots of files, it's probably a good idea to use a for loop for this. Or to generate a complete file.
After the transformation, send us the original-obfuscate.xml file. :-))
Hope that helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, not sure if that actually causes your issue (it should not), but
WARNING:toc:UnknownTOCelementbook
probably means you are trying to build an entire set with our stylesheets. You should expect some layout issues when building PDFs with this. (It works for HTML, though.)
However, that should not cause the issues. I just built one of our sets and the build ran through. (Layout issues were of course there.)
Could you use --debug instead of -vv and post the output to pastebin or some other place? If it contains proprietary information, you can also e-mail me at sknorr [at] suse [dot] de. I'll share the information with Frank.
(Also, before you re-run, remove the build directory OR re-run with --force.)
Last edit: Stefan Knorr 2015-12-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The image in file system is called bug_tracker_git_icon.png. I've tried to rename the file to bug-tracker-git-icon.png. Same problem. With another image everything works fine.
Thank you very much for your help.
Regards and good night
Martin
Last edit: Martin Köditz 2015-12-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, I figured out there is something wrong with the original Git logo. I've opened it with Gimp. After overwriting it at the original place, Daps worked without errors.
Now I can confirm: the bugs are fixed. ;-)
Thank you so much.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
great to hear you could solve the problem! Congratulations! :)
Yes, minor issues can cause big problems. In your case it was a broken image. At the moment, DAPS doesn't have any "image validation" feature. Not sure if it would be helpful, but if you think this is useful, open an enhancement request in our GitHub issue tracker.
Thanks for helping us to make DAPS better. Let us know and spread the word. ;-)
Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In case of of cryptic and non-helpful error messages like "Error 1", run DAPS with the --debug switch. This is especially helpful when it comes to FOP errors. FOP puts out several hundred lines of debug messages, therefore DAPS suppresses these messages. When running DAPS with --debug these messages are turned on in case an error occurs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
Hi,
I'm struggling with the PDF images. My HTML output looks just fine. But if I create a PDF the images are hidden. What am I doing wrong?
Thats an example:
Here is my output:
As you can see there are some missing images. But the existing ones should be in the PDF, shouldn't they?
Regards
Martin
All images need to be located in images/src/<FORMAT>/filename.<FORMAT>
Where format is one of "png, jpg, svg, fig, dia".
This ensures that images are found automatically and can be automatically be converted into other formats, if required.
The error message above suggested that you put the images into the sub folder bugs/ - this is not supported. Also make sure that image basenames must be unique across the whole image tree - having images/src/png foo.png and images/src/svg/foo.svg is not supported.
BTW: If you create HTML and PDF from the same sources, you may rather want to try the following <figure> - it allows different formats and dimensions (width/height) for PDF and HTML:
This would require "images/src/svg/bug_menu.svg" - DAPS will automatically create the png image required for HTML output. Of course using the same image formats for both HTML and FO (PDF) is supported, too:
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
Hi Frank,
thank you for your rapid response. As I mentioned above the HTML output is OK. Here can I see the correct image. In PDF there is no image.
Well, I've corrected my image paths in the whole document. Though I'm getting no errors anymore, but the images are still hidden. It doesn't matter if I use the role attribute.
As you mentioned, I'm creating the pdf and html output from the same source.
Regards
Martin
Hmmm....
Please try running daps with `--force':
This ensures that all files are rebuild. If that does not solve the problem, more debugging is needed:
Have a look at the *.fo file in /srv/www/htdocs/daps/koesterf/build/.tmp and search for one of the missing images or, alternatively, fo:external-graphic. Check if the paths to the images are valid using the following command:
BTW (unrelated to the problem): Looks like you are building from DocBook5 sources. If that is correct, use
It's the DocBook5 variant of the stylesheets and building the PDF will be much faster.
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
I think that might be the issue. You can continue to use e.g.
<imagedata fileref="bug_menu.png"/>
(i.e. without the path) but you have to move the image files underimages/src/[format]
.Yes - sorry to not have been clear enough before.
DAPS requires the directory/file layout described in
https://opensuse.github.io/daps/doc/art.daps.quick.html#ex.daps.quick.dir.doc
That way writers do not have to remind any paths when embedding images or XML documents - the file name is all that is needed. As mentioned above, it also ensures that DAPS can automatically convert to other formats.
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
The DAPS structure is created the way you mentioned above. You can find the PNGs in "/srv/www/htdocs/daps/koesterf/images/src/png".
I've checked the .fo file. There I found the entry for my image pointing to "/srv/www/htdocs/daps/koesterf/build/.profiled/noprofile/bug_menu.png". But in that noprofile directory is no image. So it's clear why there is no image shown in the PDF.
BTW: Thank you for your advice with the DB5 stylesheet. Where can I get it? I'm unable to find the correct RPM in my OpenSuse 13.2.
Martin
Congratulation, you found a bug ;-) ;-( , please see
https://github.com/openSUSE/daps/issues/316
I will fix it right away. A new release will be published soon (before Xmas) and it will contain the fix.
In the meantime please use the following workaround:
Add the following processing instruction (PI) right after the XML declaration to the MAIN file (xml/SynDesk.xml in your case):
<?xml-stylesheet href="urn:x-suse:xslt:profiling:docbook50-profile.xsl" type="text/xml" title="Profiling step"?>
The beginning of the file should now looks like this:
This should fix the problem, but should not affect the output (regardless whther it is HTML or PDF) in any other way.
The DocBook5 variant of the
/usr/share/xml/docbook/stylesheet/daps2013
stylesheets is shipped with the suse-xsl-stylesheets package. The version shipped with openSUSE 13.2 does not have them, but you could install the version from Documentation:Tools:This repository also always provides the latest DAPS version for openSUSE.
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
Well, that was not my intention. But good to know.
I've inserted the line as you mentioned above. This is the output:
On the other hand I've tried to use the daps2013-ns stylesheet. Now I'm getting following errors:
I think something is wrong with my environment. Or are there other bugs?
Regards
Martin
Hi Martin,
thanks for the helpful debug messages.
What's very suspicious is the following URL:
That URL is definitely wrong. For some reasons, the URL contains tag names. Either it's a bug in daps and the stylesheets, or your environment is screwed up.
However, you can try something different:
daps-init
and create an environment somewhere else (probably/tmp
would be good for testing). I$ daps-init --docdir /tmp/foo --docbook5
I guess, this little test should build just right. If your license or other things permit it, you can also send or attach a tarball with all of your files.
Hope this gives some hints. :-)
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
Hm... maybe that is a bug in the suse-xsl build process..? A misfiring regex or so... I also just noticed a separate bug with the DAPS stylesheets.
Martin, can you try the suse2013-ns stylesheets instead? (The DAPS stylesheets are a thin layer over those... and the DocBook 5 version of them has at least the above bug...)
(Sorry, I hope we are not confusing you with too many instructions :/ .)
Last edit: Stefan Knorr 2015-11-27
You are right, that's a bug in the daps2013/ stylesheets, but that should not be the case of the error Martin encountered - they work for me regardless of that error.
Edit: I was wrong because I overlook that this error occured when generating HTML rather than PDF. I can confirm the error Martin encountered and will do further debugging. It's definetely caused by the wrong include statements and does not occur with
Martin, there is no need to do the test Thomas has asked for. Just set
STYLEROOT
in the DC file to/usr/share/xml/docbook/stylesheet/suse2013-ns
or do not set STYLEROOT at all (in that case the Docbook stylesheets will be used). In the meantime I will try to fix the daps2013 stylesheets.Last edit: Frank Sundermeyer 2015-11-27
Status
We will test the updates beginning of next week and will release new DAPS and suse-xsl-stylesheets versions ASAP. openSUSE/SLE packages will be available shortly after release on Documentation:Tools.
Frank, thank you for the good news. I will stand by.
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
Hi Frank,
are there any news about the packages?
Anonymous, all the fixes should be packaged up now. For the moment, DAPS 2.1.5 is only available from the OBS repo Documentation:Tools.
Install from http://download.opensuse.org/repositories/Documentation:/Tools/ to get your fix.
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
Hi,
I've just installed dap version 2.1.5. But I'm still getting erros:
Have I missed anything?
Regards
Martin
HI Martin,
luckily, you found already the bug and Stefan kindly offered his help. Great!
In case you have further issues I have an additional idea I would like to share with you.
It is always a bit difficult for developers to debug and reconstruct all the problems someone else has. It helps a lot to have the source code to play with. ;-)
As your documentation contains probably sensitive information that shouldn't or couldn't shared with others, I've written an "obfuscate" template some time ago. It just copies everything, except that it rewrites all text nodes to 'x'. You can find it in the daps GitHub repository, use the stylesheet
daps-xslt/contrib/obfuscate.xsl
.Whenever you want to share some source code with us, use that stylesheet to transform your XML file. You can use
xsltproc
for this task:Unfortunately, this is a manual task at the moment. If you have lots of files, it's probably a good idea to use a for loop for this. Or to generate a complete file.
After the transformation, send us the
original-obfuscate.xml
file. :-))Hope that helps.
Hm, not sure if that actually causes your issue (it should not), but
probably means you are trying to build an entire
set
with our stylesheets. You should expect some layout issues when building PDFs with this. (It works for HTML, though.)However, that should not cause the issues. I just built one of our sets and the build ran through. (Layout issues were of course there.)
Could you use
--debug
instead of-vv
and post the output to pastebin or some other place? If it contains proprietary information, you can also e-mail me atsknorr [at] suse [dot] de
. I'll share the information with Frank.(Also, before you re-run, remove the build directory OR re-run with
--force
.)Last edit: Stefan Knorr 2015-12-09
Sorry to say, but I had to edit this answer. My message was not correct. So here is the actual status:
After some hours of investigation I found the point of failure.
The image in file system is called bug_tracker_git_icon.png. I've tried to rename the file to bug-tracker-git-icon.png. Same problem. With another image everything works fine.
Thank you very much for your help.
Regards and good night
Martin
Last edit: Martin Köditz 2015-12-10
So, I figured out there is something wrong with the original Git logo. I've opened it with Gimp. After overwriting it at the original place, Daps worked without errors.
Now I can confirm: the bugs are fixed. ;-)
Thank you so much.
Hi Martin,
great to hear you could solve the problem! Congratulations! :)
Yes, minor issues can cause big problems. In your case it was a broken image. At the moment, DAPS doesn't have any "image validation" feature. Not sure if it would be helpful, but if you think this is useful, open an enhancement request in our GitHub issue tracker.
Thanks for helping us to make DAPS better. Let us know and spread the word. ;-)
Tom
BTW:
In case of of cryptic and non-helpful error messages like "Error 1", run DAPS with the
--debug
switch. This is especially helpful when it comes to FOP errors. FOP puts out several hundred lines of debug messages, therefore DAPS suppresses these messages. When running DAPS with--debug
these messages are turned on in case an error occurs.