# PDF+Latex export creates multipage pdf, pages missing

Bug #1417470 reported by jvdberg on 2015-02-03
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Medium
Unassigned
Fix Released
Unknown
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.

Tags: Edit Tag help

## Related branches

 jvdberg (jevdberg) wrote on 2015-02-03: #1
 description: updated
su_v (suv-lp) on 2015-02-03
 David R. Bild (drbild) wrote on 2015-02-07: #2

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 on 2015-02-07: #3

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 on 2015-02-08: #4

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 on 2015-02-24: #5

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 on 2015-02-26: #6

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

 Tjitte-Jelte Peters (tjittejelte) wrote on 2015-03-30: #7

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 on 2015-03-30: #8

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

 Jan-Christoph Deinert (jan-deinert) wrote on 2015-06-02: #9

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 on 2015-07-29: #10

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 on 2015-09-17: #11

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 on 2015-11-09: #12

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

 Jiri Kosinka (jiri-kosinka) wrote on 2015-11-09: #13

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 on 2015-11-25: #14

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 on 2015-11-25: #15

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:

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 on 2015-12-17: #16

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 on 2016-02-23: #17

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  Jeremiah O'Neil (jeremiah-d-oneil) wrote on 2016-05-30: #18 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 on 2016-06-14: #19

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 on 2016-06-16: #20

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 on 2016-06-16: #21

There is a tool svg2latex:
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:

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 on 2016-08-09: #22

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 on 2016-08-09: #23

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 on 2016-10-07: #24

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

 Florian Toth (floriantoth) wrote on 2016-10-24: #25

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 on 2016-11-01: #26

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

 Boris Dalstein (dalboris) wrote on 2017-04-04: #27

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 on 2017-04-06: #28

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
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
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:
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:
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)
...

 Kurt (schneebrett) wrote on 2017-04-25: #29

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 on 2017-05-31: #30

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 on 2017-06-14: #31

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 on 2017-06-14: #32
 Mc (mc...) wrote on 2017-06-14: #33

thanks for the patch !

 tags: added: backport-proposed Changed in inkscape: status: Confirmed → Fix Committed milestone: none → 0.93
 Andreas Preikschat (googol) wrote on 2017-07-02: #34

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

 Andreas Preikschat (googol) wrote on 2017-07-02: #35

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 on 2017-07-02: #36 test(:|✔)$ inkscape -V
Inkscape 0.92+devel trunk-25-g953aae6dd1 ;2017-07-01 custom

 Max Gaukler (mgmax) wrote on 2017-07-03: #37

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 on 2017-07-03: #38

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 on 2017-07-03: #39
 Max Gaukler (mgmax) wrote on 2017-07-06: #40

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 on 2017-07-08: #41

Hey Max,

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

a90a18e6e5ac6a8d12d12043419e86e22d016efa works fine.

 Max Gaukler (mgmax) wrote on 2017-07-08: #42

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 on 2017-07-31: #43
 Changed in inkscape: milestone: 0.93 → 0.92.2 tags: removed: backport-proposed
 Launchpad Janitor (janitor) wrote on 2017-08-10: #45

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 on 2017-11-25: #46

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 on 2017-11-25: #47
 Max Gaukler (mgmax) wrote on 2017-11-26: #48

I have attached all examples I tested for future reference.

 Patrick Storz (ede123) wrote on 2017-12-05: #49

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

 Patrick Storz (ede123) wrote on 2017-12-12: #50

All recent fixes related to PDF+LaTeX export backported in

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

 Chris (matsalleh92) wrote on 2019-01-21: #51

I still get this bug with Inkscape 0.92.2 (5c3e80d, 2017-08-06)

The attached image produces 7 pages in the PDF and so is not usable in latex: https://tex.stackexchange.com/questions/243499/sharelatex-pdf-inclusion-required-page-does-not-exist-5

 Max Gaukler (mgmax) wrote on 2019-01-25: #52

Chris, the version you posted is two years old. If you are using Linux or Windows there is definitely a newer version. For Mac, there is currently no installer for the latest version because we couldn't find developers for that, but you can try MacPorts.

 Christian Peteranderl (wickedpa) wrote on 2019-02-17: #53

The bug is still existing in the newest version (0.92.4) in my case (!) and with the example "expCross.svg " of Chris (!)

 Max Gaukler (mgmax) wrote on 2019-02-17: #54

Confirmed for 1.0alpha (66f58bd637, 2019-02-10) and current 0.92.x branch (4f452baadd, 2019-02-17, custom): "expCross.svg" from Chris creates a PDF with 7 pages, but a TeX file which includes "page=8".

 Changed in inkscape: status: Fix Released → Triaged milestone: 0.92.2 → 1.0alpha assignee: Max Gaukler (mgmax) → nobody
 Max Gaukler (mgmax) wrote on 2019-02-17: #55

What we need to solve the bug is a minimized version of the problem. Can anyone try to remove as much as possible from the example file without removing the error?

 Chris (matsalleh92) wrote on 2019-02-17: #56

It is to do with layers. The example file can be made to work by ungrouping everything and putting everything to the bottom layer (move selection to bottom).

The problem occurs when things are forced to top and bottom layers instead of just promoting the layer of a selected object one at a time.

 Max Gaukler (mgmax) wrote on 2019-02-18: #57

Thank you for the hint. However, before a fix can be developed, we need a *minimal* example (maybe two rectangles and a text, or however simple you can make it) for debugging the code.

Please understand that is (almost) impossible to debug this with a complicated file as the above example, so there will (most probably) not be a fix before someome has found a minimal example. Even if you paid someone to do develop a fix, then this person would look for such an example as the first step of fixing the bug. As we are all volunteers, developers' time is very limited, so your help with creating a minimal example is needed before a fix will be developed.

 Szymon Mikulicz (ashymad) wrote on 2019-02-24: #58

Here I've attached a minimal file that triggers this bug for me. It contains only a dot and a letter "s".

 Changed in inkscape: milestone: 1.0alpha → 1.0