PDF+Latex export creates multipage pdf, pages missing

Bug #1417470 reported by jvdberg on 2015-02-03
210
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Max Gaukler
inkscape (Debian)
Fix Released
Unknown
inkscape (Ubuntu)
Medium
Unassigned

Bug Description

In 0.91 the z-order information in svg is used to create multipage PDF+LaTeX documents as per bug 771957. However, for the SVGs I have been converting to PDF+LaTeX in this way, the TeX-file instructs to load more pages than the PDF has, for example the PDF has only three pages and the TeX file also includes page=4. This basically breaks the PDF+LaTeX export for me and I have to use EPS+LaTeX + epstopdf package.

The bug occurs on OpenSuse 13.1 and Windows 8.1.

Attached a zip file with two svg files and their broken PDF+LaTeX counterparts.

jvdberg (jevdberg) wrote :
description: updated
su_v (suv-lp) on 2015-02-03
tags: added: exporting latex pdf
David R. Bild (drbild) wrote :

Thanks for the report. The files that I originally wrote the z-ordering patch for also exhibit this problem now too. (On openSUSE 13.2.)

For now, you can manually edit the generated *.pdf_tex files to remove the offending lines. They should be of the form:
\put(...){\includegraphics[...,page=...]{*.pdf}}%

The way Cairo exports pages must have changed. If I can get the 0.91 source to build on my machine now, I'll try to get a patch submitted. When I looked into this ~3 weeks ago, the build was broken.

Changed in inkscape:
assignee: nobody → David R. Bild (drbild)
David R. Bild (drbild) wrote :

Just to clarify, you should only need to remove the last "\includegraphics" line from the *.pdf_tex file. On my files, only one extra missing page was being referenced.

David R. Bild (drbild) on 2015-02-07
Changed in inkscape:
status: New → Confirmed
David R. Bild (drbild) wrote :

This issue with objects in groups/layers that have a mask, clip, or partial opacity applied. Those get rendered between the two two ends of a cairo_push_group() and a cairo_pop_group() pairing. We call cairo_show_page() to switch to a new page in the pdf, but a group is active, Cairo ignores the call and all the graphics end up on the same pdf page.

I must have never tested an SVG with clips, masks, or group-/layer-level opacity.

For a fix, ideally, a call to cairo_show_page() would render every thing in the current group(s) to the current page, then start a new page, but keep the group stack active (with its associated transforms). Subsequent items would go into the group (getting the same group transformations applied) and be rendered on to the new pdf page. But I don't think Cairo can function like that, without introducing many other bugs.

Instead, we should just not interleave text and graphics between a cairo_push_group()/cairo_pop_group() pair. All the graphics in that group should be rendered to one pdf page and all the text should be rendered on top of that page.

This method will properly interleave text/graphics for many images and not break others. Images with text inside of clipped/masked/partially opaque groups may be incorrect, but they were before as well.

I can successfully compile master again, so I'll try to get a patch for this prepared within the next 7-10 days.

su_v (suv-lp) on 2015-02-08
Changed in inkscape:
importance: Undecided → Medium
Leo Filippini (le-filippini) wrote :

I'm having the same issue, Inkscape 0.91 on Mac Os X 10.10.2, but I can still compile my latex files correctly and the output looks the same as before.

Buembel (buembel) wrote :

I do experience the same problem. Latex Export has become impossible for now with 0.91, I need to go back to 0.4x.

Currently, this problem still persists. Every time I compile a Latex document with changes in (one of) the .svg figure(s), I have to manually remove the last '\includegraphics' line from the created .pdf_tex file(s).
When can we expect a patch for this issue? Thanks!

Johan Engelen (johanengelen) wrote :

David, how about adding an option to revert to old behavior ? (i.e. always put text on top)

Same issue with inkscape 0.91 portable on Windows 7. I can force the system to compile by changing the page number in the .pdf_tex file, i.e., when it says "page=3" and there are only two pages I change the text to "page=2".

gpunktet (kilian-grundl) wrote :

the bug is also apparant for the Ubuntu package in the 15.04 distribution

affects: inkscape → ubuntu
su_v (suv-lp) on 2015-07-29
Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed
Leo Filippini (le-filippini) wrote :

The export is now broken on Mac OS X, although I reported a few months ago that it was working. Manually editing the .pdftex file solve the issue.

Jiri Kosinka (jiri-kosinka) wrote :

Please fix this, it has broken my pipeline. I use Inkscape with pdfLaTeX for papers, lecture slides, etc.

Jiri Kosinka (jiri-kosinka) wrote :

There might actually be a simple temporary fix: just introduce an option for generating a pdf from svg which ignores all text. We could then use --export-latex (combined with --export-pdf) first and then the new --export-noText to fix the `multi-page' pdf.

Cimbali (q-me-p) wrote :

Isn't it possible to get a quick fix to roll back #771957, ie just render a flat PDF without text and then use latex to put all text on top?

Cimbali (q-me-p) wrote :

I know this isn't the ideal solution, but it's the simple one, and will probably do until someone with better knowledge of cairo rendering has time to work on this.

I disabled multiplpe pages in pdf+latex output, see my branch:
https://code.launchpad.net/~q-me-p/inkscape/singlepage-latex-pdf

This makes the feature of exporting to latex usable again, but always writing the text on top of all the layers (with whatever transparency that text has), as was the old behaviour.

Biber (c-woltmann) wrote :

I just updated to Inkscape 0.91 and ran into the same trouble.
I call inkscape from inside LaTeX as I think many of you do as well.

Here is a solution that works fine for me (and because it uses some standard commands ... only for Linux). It essentially goes through the inkscape generated TEX files (on-the-fly) and removes bad stuff from them (like strings containing '\\' or these nasty wrong page numbers...). Some of the code is not my work, but recycled from different sources I can't recall (sorry for not citing them properly).

%######## Put all this code _before_ the '\begin{document}' statement. ###########

%Tell LaTeX where to look for graphics (the './.tmp /' folder will be used by the '\includesvg' command for the inkscape PDF+TEX output, './Figures/' is where all my SVGs are stored.)

\graphicspath{ {./Figures/} {./.tmp/} }

%We'll never call this manually, it's just used by the '\includesvg' command to avoid unnecessary rebuilding of PDFs

\newcommand{\executeiffilenewer}[3]{\ifnum\pdfstrcmp{\pdffilemoddate{#1}}{\pdffilemoddate{#2}}>0{\immediate\write18{ [ -d ./.tmp/ ] || mkdir ./.tmp; #3}}\fi}

%Here it comes... It is necessary that _all_ our SVG files are collected (e.g. by symlinking) in only one folder (here it is called './Figures/'. If you want a different one, make sure to change the path in this command as well.

\newcommand{\includesvg}[2][\textwidth]{\def\svgwidth{#1}\executeiffilenewer{./Figures/#2.svg}{./.tmp/#2.pdf}{\unexpanded{PDF_FILE="./.tmp/#2.pdf"; inkscape -z --file=./Figures/#2.svg --export-pdf=$PDF_FILE --export-latex; sed -i 's/\\\\/\n/g' ${PDF_FILE}_tex; MAXPAGE=$(pdfinfo $PDF_FILE | grep -oP "(?<=Pages:)\s*[0-9]+" | tr -d " ") ; sed -i "/page=$(($MAXPAGE+1))/,\${/page=/d}" ${PDF_FILE}_tex; } } \input{./.tmp/#2.pdf_tex}}

%##############################################################

You can then use the '\includesvg' command similarly (though not so advanced) to '\includegraphics', e.g.

\begin{figure}
     \centering
     \includesvg[0.5\textwidth]{My_Nice_SVG_File} %Where the file is located/linked at: ./Figures/My_Nice_SVG_File.svg
     \caption{My_Caption]
     \label{My_Label}
\end{figure}

Hope that is helpful for some of you,

Greetings, Bb

Hobbyblobby (hobbyblobby) wrote :

I have the same problem here with Ubunut 12.04.5 and self-compiled inkscape 0.91.

Since I compile my LaTeX stuff with a Makefile, I used the following workaround:
graphics: $(SLIDE_DIR)/*.svg
 for i in $?; do\
  inkscape -z -f "$$i" --export-latex -A "$$(dirname $$i)/$$(basename $$i .svg).pdf" -C; \
  PAGES=$$(pdfinfo "$$(dirname $$i)/$$(basename $$i .svg).pdf" | grep Pages | cut -d" " -f11); \
  for j in $$(egrep "includegraphics.*page=" "$$(dirname $$i)/$$(basename $$i .svg).pdf_tex"); do\
   CHECKPAGE="$$(echo $$j | sed 's/^.*page=\([0-9]*\).*$$/\1/g')";\
   if [ $$CHECKPAGE -gt $$PAGES ]; then\
    sed -i 's/^.*includegraphics.*page='$$CHECKPAGE'.*$$//g' "$$(dirname $$i)/$$(basename $$i .svg).pdf_tex";\
   fi;\
  done;\
 done

Maybe it is not so elegant, but for it works. What does this target do? At first it loops over all .svg files in my "$SLIDE_DIR" directory and converts the files with inkscape. Then it look how much pages the resulting pdf file has. Then it loops over all includegraphics in the coresponding pdf_svg file to find entries where "page=X" has a X greater then the pages in the pdf. If this is the case, the line is deleted with sed. I guess there is a shorter solution with awk, but I am not so familiar with awk.

Changed in inkscape (Debian):
status: Unknown → Confirmed

Affects me in Manjaro with inkscape 0.91 from the official Arch repos, and affected me in Quirky compiled from source. For a while I resorted to 0.48 patched for compatibility with recent cairo and poppler, but now I'm using Hobbyblobby's solution with some adjustments:

##MAKEFILE##
FIG_DIR=data/figures
SVG2PDFTEX_SVG_FILES := $(wildcard $(FIG_DIR)/svg2pdftex_in/*.svg)
SVG2PDFTEX_PDF_FILES=$(patsubst $(FIG_DIR)/svg2pdftex_in/%.svg,$(FIG_DIR)/svg2pdftex_out/%.pdf,$(SVG2PDFTEX_SVG_FILES))
SVG2PDFTEX_TEX_FILES=$(patsubst $(FIG_DIR)/svg2pdftex_in/%.svg,$(FIG_DIR)/svg2pdftex_out/%.pdf_tex,$(SVG2PDFTEX_SVG_FILES))

main.pdf: main.tex $(SVG2PDFTEX_PDF_FILES) $(SVG2PDFTEX_TEX_FILES)
 # call your favourite build tool

$(FIG_DIR)/svg2pdftex_out/%.pdf $(FIG_DIR)/svg2pdftex_out/%.pdf_tex: $(FIG_DIR)/svg2pdftex_in/%.svg
 inkscape -z -f $< --export-latex -A "$$(dirname $@)/$$(basename $< .svg).pdf" -C ; \
 PAGES=$$(pdfinfo "$$(dirname $@)/$$(basename $< .svg).pdf" | grep Pages | cut -d" " -f11) ; \
 for j in $$(egrep "includegraphics.*page=" "$$(dirname $@)/$$(basename $< .svg).pdf_tex") ; do \
  CHECKPAGE="$$(echo $$j | sed 's/^.*page=\([0-9]*\).*$$/\1/g')" ; \
  if [ $$CHECKPAGE -gt $$PAGES ] ; then \
   sed -i 's/^.*includegraphics.*page='$$CHECKPAGE'.*$$//g' "$$(dirname $@)/$$(basename $< .svg).pdf_tex" ; \
  fi ; \
 done
##MAKEFILE(END)##

wherein I use a multitarget pattern rule to allow make to decide when a figure needs to be reprocessed, and some automatic variables to get the target name and directory; see http://www.gnu.org/software/make/manual/make.html#Pattern-Examples

The main difference is that the target is a file instead of .PHONY and the rule only generates the target (and its pdf or pdf_tex complement) rather than running through the whole svg directory. Make should recreate %.pdf and %.pdf_tex when at least one is missing or older than %.svg, for each %.svg in SVG2PDFTEX_SVG_FILES, but otherwise won't waste its time. One could specify the required figures manually per project instead of the wildcard and patsubst method, or maybe automatically when building with latexmk; I think I recall that it would attempt "make (file)" if pdflatex reported (file) were missing.

Mark Rein (gimpsmart) wrote :

What is the current status of this? I absolutely depend on this feature in my day to day work.

Is there anything newer than 0.48 I can install that still works? (Binary for Windows needed.)

Thanks a lot!

edub (e-dub) wrote :

I am also looking for a solution or a workaround. Currently using Ubuntu 16.04 and the inability to use this function is quite unfortunate. I attempted in vain to write a quick workaround via Python and pypdf. Thereafter I tried to compile Inkscape 0.48.5, but this was also not a success.

Does anyone have any ideas?

Many thanks!

Richard Henwood (rjhenwood) wrote :

There is a tool svg2latex:
https://github.com/johnbartholomew/svg2latex/blob/master/ReadMe.md
that I don't have any experience with, but may work.

I wrote a tool with the same name, svg2latex, and maintained it for a few years:
https://sites.google.com/site/richardhenwood/project/svg2latex2

However, I haven't touched it for ~5 years, and I think it's currently broken (it has a very brittle design). If you have success with johnbartholomew's code, please write back so I can update my tool page to point to that.

Mattia Rizzolo (mapreri) on 2016-07-16
affects: ubuntu → inkscape (Ubuntu)
Changed in inkscape (Ubuntu):
assignee: David R. Bild (drbild) → nobody
edub (e-dub) wrote :

Unfortunately, I was unable to get svg2latex to work for me. Has anyone been able to install/build 0.48.x in Ubuntu 16.04?

Richard Henwood (rjhenwood) wrote :

You maybe able to install the 0.48.4 binary from the 14.04 repository:

http://archive.ubuntu.com/ubuntu/pool/main/i/inkscape/inkscape_0.48.4-3ubuntu2_amd64.deb

Eric Baumann (eric-mannbaum) wrote :

SOLVE THIS PLEASE ! It really sucks. Makes inkscape USELESS for me !

Florian Toth (floriantoth) wrote :

A quick fix to get the svg+tex > pdflatex pipline working again is to use eps-export and convert to pdf:

inkscape -z -D --file=#1.svg --export-eps=#1.eps --export-latex
epstopdf #1.eps
sed "s/[.]eps/.pdf/g" #1.eps_tex > #1.pdf_tex

where #1 is your inkscape file.

Hobbyblobby (hobbyblobby) wrote :

"[Bug 470] Re: PDF+Latex export creates multipage pdf, pages missing"
Eric Baumann doc

Boris Dalstein (dalboris) wrote :

Just adding my voice here. This bug makes PDF+LaTeX pretty unusable as of now. Rolling back to previous behaviour seems advisable, at least until an actual fix is made.

Matic (matic-ivancic) wrote :
Download full text (3.3 KiB)

I found the same problem. On windows I fixed it with installing Inkscape version 0.48 but I cannot do this under ubuntu 16.04. Therefore I wrote a script in python. There is my simple script for converting .svg images to .pdf_tex format:

'''
Inkscape 0.92 have a bug while exporting svg image to pdf_tex.
The pdf_tex my be quite usefull while writting manuscripts in Latex:
https://waterprogramming.wordpress.com/2015/07/28/embedding-figure-text-into-a-latex-document/

The problems is because number of pages in pdf and pdf_tex and exported
files usually differs (bug). Both options are possible: number of pages
in pdf can be higher or lower to the number of pages, specified in pdf_tex
file.

Presented solution is tested on Ubuntu 16.04 and is written in python 2.7
(pypdf is only available for python 2).

Run this script: put svg figure name as argument:
python pdf_correct.py figure.svg

Created on Thursday 6 Apr 2017.

@author: Matic
'''

import sys
import os
from pyPdf import PdfFileReader
import re
import shutil

if len(sys.argv) != 2:
 print 'You must put figure name as an argument.'
 sys.exit()

svg_name = sys.argv[1]
pdf_name = svg_name.replace('svg', 'pdf')
tex_name = pdf_name.replace('pdf', 'pdf_tex')

# run inkscape and make pdf_tex
# os.system('inkscape fig_sketch.svg --export-pdf fig_sketch.pdf --export-latex')
os.system('inkscape %s --export-pdf %s --export-latex' % (svg_name, pdf_name))

# read number of pages in pdf file
pdf = PdfFileReader(open(pdf_name,'rb'))
n_pages_pdf = pdf.getNumPages()
print '# pages in pdf: ', n_pages_pdf

# find number of pages in pdf_tex file - use regular expresions
pattern = re.compile('page=\d+')
n_pages_tex = 0
with open(tex_name, 'r') as f:
 for line in f:
  res = re.search(pattern, line)
  if res:
   i = int(res.group().replace('page=', ''))
   n_pages_tex = max(i, n_pages_tex)
   # save line form
   page_line = line

print '# pages in pdf_tex: ', n_pages_tex

# make new, corrected pdf_tex file if it is needed
tex_name_new = tex_name + '_new'

if n_pages_tex < n_pages_pdf:
 # in this case you need to add/include additional pages
 with open(tex_name, 'r') as f_old:
  with open(tex_name_new, 'w') as f_new:
   for line in f_old:
    if '\end{picture}%' not in line:
     # rewrite almost all lines
     f_new.write(line)
    else:
     # add missing pages
     for i in range(n_pages_tex+1, n_pages_pdf+1):
      # page_line - use saved form of line
      res = re.search(pattern, page_line)
      old_part = res.group()
      new_part = 'page=%d' % i
      f_new.write(page_line.replace(old_part, new_part))
     f_new.write(line)
 shutil.move(tex_name_new, tex_name)

elif n_pages_tex > n_pages_pdf:
 # you need to delete included pages that not exist in pdf file
 with open(tex_name, 'r') as f_old:
  with open(tex_name_new, 'w') as f_new:
   for line in f_old:
    res = re.search(pattern, line)
    if res:
     # if 'page=' is in line, check the numeber
     i = int(res.group().replace('page=', ''))
     if i <= n_pages_pdf:
      f_new.write(line)
     # else:
     # you have a problem here, don't rewrite line to new file

    else:
     # rewrite all lines without 'page='
     f_new.write(line)
...

Read more...

Kurt (schneebrett) wrote :

I am not sure if this is useful to everyone here, but I found a solution which is fine for me and much better than changing code manually.

I am having the same problem, that Inkscape, when exporting to pdf_tex, sometimes creates to much pdf-pages, causing an error during the creation of the document.

To avoid this, just before you safe your *.svg to *.pdf mark all text you have in your document, then put it to the highest level/layer (don't know how it's called in the english inskape). This should remove the unnecessary pages in the pdf.

Max Gaukler (mgmax) wrote :

I developed a fix in lp:~mgmax/inkscape/pdf-tex-fix-group , feedback is appreciated.

Basically, that cairo_push_group() is active, suppresses the noneffective cairo_show_page() and after the next successful page it adds blank pages to the PDF so that the page numbers match again.

As far as I tested, there is no difference for cases where it worked before. In the cases where it didn't work before ("decelresults" and "rotspectrum" attached to this bugreport), the TeX now compiles and the output looks correct. The Z-ordering is not perfect, but I'm afraid there is no better solution which is not horribly complicated.

Max Gaukler (mgmax) wrote :

I uploaded the patch to gitlab: https://gitlab.com/inkscape/inkscape/merge_requests/13

I tested it using the .svg files in the attachment of the very first comment of this report, and the TeX file in my attachment here.

Mc (mc...) on 2017-06-14
Changed in inkscape:
assignee: nobody → Max Gaukler (mgmax)
Mc (mc...) wrote :

thanks for the patch !

tags: added: backport-proposed
Changed in inkscape:
status: Confirmed → Fix Committed
milestone: none → 0.93
Andreas Preikschat (googol) wrote :

I build inkscape from source and I found a file which now causes inkscape to hang.

Andreas Preikschat (googol) wrote :

inkscape keeps hanging on this command:
test(:|✔)$ inkscape -z -D --file=test.svg --export-pdf=test.pdf --export-latex -- INSERT --
WARNING: unknown type: pencil:metadata
WARNING: unknown type: pencil:metadata
WARNING: unknown type: pencil:metadata
WARNING: unknown type: pencil:metadata
WARNING: unknown type: pencil:metadata
WARNING: unknown type: pencil:metadata
WARNING: unknown type: pencil:metadata
WARNING: unknown type: pencil:metadata
WARNING: unknown type: pencil:metadata

** (inkscape:1314): WARNING **: PDF+TeX output: Found text inside a clipped/masked group. This is not supported, the Z-order will be incorrect. Blank pages will be added to the PDF output to work around bug #1417470.

** (inkscape:1314): WARNING **: PDF+TeX output: issuing blank PDF page (workaround for previous error)

Andreas Preikschat (googol) wrote :

test(:|✔)$ inkscape -V
Inkscape 0.92+devel trunk-25-g953aae6dd1 ;2017-07-01 custom

Max Gaukler (mgmax) wrote :

Hi Andreas, I cannot reproduce your problem with the latest source version:

$ cd build
$ make -j8 && ./bin/inkscape -z -D --file=/home/max/code/inkscape/fixed-bug-1417470/regression/test.svg --export-pdf=test.pdf --export-latex
[...]
** (inkscape:20415): WARNING **: PDF+TeX output: Found text inside a clipped/masked group. This is not supported, the Z-order will be incorrect. Blank pages will be added to the PDF output to work around bug #1417470.

** (inkscape:20415): WARNING **: PDF+TeX output: issuing blank PDF page (workaround for previous error)
$ ./bin/inkscape -V

** (process:20430): WARNING **: Units file /usr/local/share/inkscape/ui/units.xml is missing: Failed to open file '/usr/local/share/inkscape/ui/units.xml': No such file or directory

Inkscape 0.92+devel trunk-61-gcd5a5eac59 2017-07-02

Andreas Preikschat (googol) wrote :

Hallo Max,

interestingly the example I uploaded works now. But the other example attached does not work, I doubled check this. I also compiled again: Inkscape 0.92+devel trunk-61-gcd5a5eac59 2017-07-02

Regards

Andreas Preikschat (googol) wrote :
Max Gaukler (mgmax) wrote :

Sorry, but the new one also works for me on Debian stretch. (0.92+devel trunk-61-gcd5a5eac59 2017-07-02)
Also with the very latest (Inkscape 0.92+devel trunk-90-g42bf908b41 2017-07-06) from a few minutes ago (Take care, they changed some dependencies: I needed to install libsoup2.4-dev, remove the whole build folder and run cmake again, so that it finally compiled)

Could you try to tracking this down further, by finding out which commit broke it (git bisect), and additionally by getting a backtrace at where it gets stuck?

Andreas Preikschat (googol) wrote :

Hey Max,

I tracked this down to commit https://gitlab.com/inkscape/inkscape/commit/d6f2d85a424751ac9dd468949a950ecc46148ff2

a90a18e6e5ac6a8d12d12043419e86e22d016efa works fine.

Max Gaukler (mgmax) wrote :

To make sure that it isn't just something special about my system, I also tested it on the offical inkscape-ci-docker image (based on Ubuntu, and therefore not much different), and everything is fine there as well: https://gitlab.com/mgmax/inkscape/-/jobs/21660444

Please give more information on the OS you are using. If you know how to do it, a docker file or something similarly automated would be perfect to reproduce the issue without manually installing your environment.

My best guess is that whatever OS/distro you are using has other versions of glibc and jemalloc, which either contain a bug or reveal a bug in inkscape. Can you also trigger the bug if you revert my changes on top of the current master (git revert e4dea66a338824037b6c35b262aa8db4004b6581)? If yes, it's not my patch, but definitely something else at fault. Anyway, this issue is so weird that you should ask for help on the inkscape-devel mailinglist.

Patrick Storz (ede123) wrote :
Changed in inkscape:
milestone: 0.93 → 0.92.2
tags: removed: backport-proposed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package inkscape - 0.92.2-1

---------------
inkscape (0.92.2-1) unstable; urgency=medium

  * New upstream version 0.92.2.
    http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92.2
    + Fix PDF+TeX output for text inside groups with clip/mask.
      Closes: #823953; LP: #1417470
  * Update the upstream signing keys.
  * Bump Standards-Version to 4.0.1, no changes needed.

 -- Mattia Rizzolo <email address hidden> Wed, 09 Aug 2017 11:36:38 +0200

Changed in inkscape (Ubuntu):
status: Confirmed → Fix Released
Changed in inkscape (Debian):
status: Confirmed → Fix Released
jazzynico (jazzynico) on 2017-08-31
Changed in inkscape:
status: Fix Committed → Fix Released
Patrick Storz (ede123) wrote :

As the previous fix only worked around the issue by adding blank pages to the output I had another shot at fixing this. I created a merge request with a "proper" fix that actually outputs partial renderings of the final document which can then be stacked in the LaTeX document with the text sandwiched in between, see
https://gitlab.com/inkscape/inkscape/merge_requests/135

As the renderer (especially the hack we use to make PDF+LaTeX work) is a fragile thing and I'm not too familiar with it yet this requires a lot of testing. I'd appreciate if you could check with your own samples if Inkscape produces proper output.

Attached is an example document that should highlight the new functionality.

Patrick Storz (ede123) wrote :
Max Gaukler (mgmax) wrote :

I have attached all examples I tested for future reference.

Patrick Storz (ede123) wrote :

Fix committed in
https://gitlab.com/inkscape/inkscape/commit/dae7facca7b1bf5ce99aaf9dc71b2da8b46f56c8

Please test this as I want to back-port the fix to 0.92.x if no issues are found.

Patrick Storz (ede123) wrote :

All recent fixes related to PDF+LaTeX export backported in
https://gitlab.com/inkscape/inkscape/compare/af5ac6bc522ff4b715d482d3eda11e0e0408ad15...cb54205aa21bcd227c62fce1a356f6f2c6039b64

This should fix all remaining issues with missing pages in the output and produce proper stacking order of text and graphics in all cases.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.