PDF+Latex export creates multipage pdf, pages missing

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.

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.

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.

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.

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!

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".

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

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.

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

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.

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?

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.

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

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.

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.

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!

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!

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.

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?

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

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

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.

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

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.

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

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.

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.

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.

merged to trunk in https://gitlab.com/inkscape/inkscape/commit/9b4f34f42d59ccbd192d9895f4996d97a7ea50d2

thanks for the patch !

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

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)

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

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

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

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?

Hey Max,

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

a90a18e6e5ac6a8d12d12043419e86e22d016efa works fine.

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.

Fix backported to 0.92.x in
https://gitlab.com/inkscape/inkscape/commit/7b17ba600c5f9574f14418fd3c267ff908ac12c9

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

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.

I have attached all examples I tested for future reference.

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.

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.

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

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.

Please test again with https://inkscape.org/de/release/inkscape-0.92.4/

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

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".

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?

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.

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.

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

Greetings!

I have to share bad news with you.
Approximately few months ago I have gained access to your devices, which you use for internet browsing.
After that, I have started tracking your internet activities.

Here is the sequence of events:
Some time ago I have purchased access to email accounts from hackers (nowadays, it is quite simple to purchase such thing online).
Obviously, I have easily managed to log in to your email account (<email address hidden>).

One week later, I have already installed Trojan virus to Operating Systems of all the devices that you use to access your email.
In fact, it was not really hard at all (since you were following the links from your inbox emails).
All ingenious is simple. =)

This software provides me with access to all the controllers of your devices (e.g., your microphone, video camera and keyboard).
I have downloaded all your information, data, photos, web browsing history to my servers.
I have access to all your messengers, social networks, emails, chat history and contacts list.
My virus continuously refreshes the signatures (it is driver-based), and hence remains invisible for antivirus software.

Likewise, I guess by now you understand why I have stayed undetected until this letter...

While gathering information about you, I have discovered that you are a big fan of adult websites.
You really love visiting porn websites and watching exciting videos, while enduring an enormous amount of pleasure.
Well, I have managed to record a number of your dirty scenes and montaged a few videos, which show the way you masturbate and reach orgasms.

If you have doubts, I can make a few clicks of my mouse and all your videos will be shared to your friends, colleagues and relatives.
I have also no issue at all to make them available for public access.
I guess, you really don't want that to happen, considering the specificity of the videos you like to watch, (you perfectly know what I mean) it will cause a true catastrophe for you.

Let's settle it this way:
You transfer $950 USD to me (in bitcoin equivalent according to the exchange rate at the moment of funds transfer), and once the transfer is received, I will delete all this dirty stuff right away.
After that we will forget about each other. I also promise to deactivate and delete all the harmful software from your devices. Trust me, I keep my word.

This is a fair deal and the price is quite low, considering that I have been checking out your profile and traffic for some time by now.
In case, if you don't know how to purchase and transfer the bitcoins - you can use any modern search engine.

Here is my bitcoin wallet: 16aqr3rXxCtxa8AK3ErftnBQLfzyyhjpXJ

You have less than 48 hours from the moment you opened this email (precisely 2 days).

Things you need to avoid from doing:
*Do not reply me (I have created this email inside your inbox and generated the return address).
*Do not try to contact police and other security services. In addition, forget about telling this to you friends. If I discover that (as you can see, it is really not so hard, considering that I control all your systems) - your video will be shared to public right away.
*Don't try to ...