I want to convert a PDF or sequence-of-images to a flip based effect in GIF (similar to the one below).
Is there any softwares available handy I could use to produce this output? or do I have to write scripts using imageMagicK? please suggest?
Thanks in advance!
Cool project! This isn't production-ready, military-hardened, bullet-proof code, but the following will do most of the heavy lifting as regards getting set up, appending the individual pages, distorting pages as they turn and finally putting the whole lot together in an animated GIF sequence.
#!/bin/bash
################################################################################
# flipbook
# Mark Setchell
#
# Give me 4 pages as parameters and I create an animated GIF book out of them
# called book.gif.
#
# Requires ImageMagick
################################################################################
# Names of the 4 pages
p0=${1:-page0.gif} # Use first arg, or "page-0.gif" if none given
p1=${2:-page1.gif}
p2=${3:-page2.gif}
p3=${4:-page3.gif}
# Get width and height of images - I assume, but do not check all are identical sizes
read w h < <(convert "$p0" -format "%w %h" info: )
((twow=w+w))
# Layout first and last flat double-page spreads
convert "$p0" "$p1" +append frame0.png
convert "$p2" "$p3" +append frame4.png
# Make right page taller and thinner and save as "distorted.png"
((deltah=20*h/100))
((deltaw=20*w/100))
((hplusdeltah=h+deltah))
((wminusdeltaw=w-deltaw))
((hplus2deltah=h+deltah+deltah))
points="0,0 0,$deltah $wminusdeltaw,0 $wminusdeltaw,0 $wminusdeltaw,$hplus2deltah $wminusdeltaw,$hplus2deltah 0,$hplus2deltah 0,$hplusdeltah"
convert "$p1" +matte -virtual-pixel transparent \
-resize ${wminusdeltaw}x${hplus2deltah}! +repage \
-distort Perspective "$points" +repage distorted.png
# Make second frame by overlaying distorted right page ontop of pages 0 and 3
convert "$p0" "$p3" +append \
-bordercolor white -border 0x$deltah \
+repage \
distorted.png \
-geometry +${w}x \
-composite frame1.png
# Make left page taller and thinner and save as "distorted.png"
((deltaw=70*w/100))
((wminusdeltaw=w-deltaw))
points="0,0 0,0 $wminusdeltaw,0 $wminusdeltaw,$deltah $wminusdeltaw,$hplus2deltah $wminusdeltaw,$hplusdeltah 0,$hplus2deltah 0,$hplus2deltah"
convert "$p2" +matte -virtual-pixel transparent \
-resize ${wminusdeltaw}x${hplus2deltah}! +repage \
-distort Perspective "$points" +repage distorted.png
# Make third frame by overlaying distorted left page ontop of pages 0 and 3
convert "$p0" "$p3" +append \
-bordercolor white -border 0x$deltah \
+repage \
distorted.png \
-geometry +${deltaw}x \
-composite frame2.png
# Make left page taller and thinner and save as "distorted.png"
((deltaw=20*w/100))
((wminusdeltaw=w-deltaw))
points="0,0 0,0 $wminusdeltaw,0 $wminusdeltaw,$deltah $wminusdeltaw,$hplus2deltah $wminusdeltaw,$hplusdeltah 0,$hplus2deltah 0,$hplus2deltah"
convert "$p2" +matte -virtual-pixel transparent \
-resize ${wminusdeltaw}x${hplus2deltah}! +repage \
-distort Perspective "$points" +repage distorted.png
# Make fourth frame by overlaying distorted right page ontop of pages 0 and 3
convert "$p0" "$p3" +append \
-bordercolor white -border 0x$deltah \
+repage \
distorted.png \
-geometry +${deltaw}x \
-composite frame3.png
# Make final animation from frame0.png...frame4.png
convert -gravity center -delay 100 frame*.png -background white -extent ${twow}x${hplus2deltah} book.gif
So, if you start with the following as page0.gif, page1.gif, page2.gif and page3.gif...
You will get this as book.gif
If your book has more than 4 pages, you can do four at a time and then append the animations quite simply.
Updated Answer
It seems you are unfortunate enough to have to use Windows - which is very cumbersome in BATCH. I am no expert, but can get around in BATCH a little. I think the script above is pretty easy to translate though. I'll get you started but you will need to do some yourself - you can always ask a new question if you get stuck - questions are free!
The first part of the script just picks up the parameters supplied on the command line, so it'll look like this:
REM Pick up commandline parameters
set p0=%1
set p1=%2
set p2=%3
set p3=%4
Then we need to work out the width and height of the input images, something like this:
REM Get width and height of images in variable "w" and "h"
FOR /F %%A IN ('identify -format "w=%%w\nh=%%h" %p0%') DO set %%A
All the stuff in my original script inside ((..)) is just simple maths which can be done in BATCH using SET /A, so the lines that look like this:
((twow=w+w))
((deltah=20*h/100))
will look like this:
SET /A TWOW=w+w
SET /A DELTAH=20*h/100
The rest is just convert commands - you will need to do a couple of things there:
Replace line continuations at ends of lines, so change \ to ^
Where I use $variable or ${variable}, replace it with %variable%
Double any % signs I have, so % becomes %%
Change \( to ^( - I think
change any single quotes ' to double quotes "
Best to just work through it and see what happens as you convert each line and ask another question if you can't work it out.
There is some good info at these places - ss64 - general, ss64 - set command on BATCH in general. Also, an English guy called Alan Gibson, uses IM with Windows very competently and you can see his scripts here, and also more generally here for inspiration on how to be effective with IM under Windows.
Related
I am working with over thousands PDF files for a Sheet Music publisher.
All of these PDF files needs a preview PDF. A watermark for PDF files can easily be removed so I am asking for a true way to watermark our PDF:s in a batch operation.
PDF->Apply Watermark->JPG->Back to PDF
How can I do this? Is there a good tool for this operations?
The free route
ImageMagick can do the complete process for you, especially with the composite command's -watermark operator.
#!/bin/sh
# ImageMagick will pick the correct conversion formats based on filename suffixes, or maybe actual binary content?
InputPDF=$1
WatermarkImg=$2
OutputPDF=$3
pdfToImage=pdfToImage.png
imageWithWatermark=imageWithWatermark.png
# Convert PDF to image
convert \
-density 300 \
-trim \
"$InputPDF" \
-quality 100 \
-flatten \
-sharpen 0x1.0 \
$pdfToImage
# Add watermark to intermediate image
composite \
-dissolve 15 \
-tile \
"$WatermarkImg" \
$pdfToImage \
$imageWithWatermark
# Convert intermediate image back to PDF
convert \
$imageWithWatermark \
"$OutputPDF"
# Clean up
rm $pdfToImage $imageWithWatermark
I find the PDF to image conversion acceptable in terms of quality, though you can see some differences when looking at the before and after side-by-side, especially in how bolded glyphs seem less bold:
You can check this good post and its answers for a number of options for converting a PDF to an image, Convert PDF to image with high resolution.
I checked out PDFtoPPM, which was also highly mentioned in that thread, and I still see some degrading of the bolded fonts when converted:
Some more tiling Magick
I used this copyright symbol from Wikimedia Commons and this ImageMagick script:
#!/bin/sh
Infile="Copyright.png"
Outfile="Copyright_tiled.png"
h2=$(convert $Infile -format "%[fx:round(h/2)]" info:)
convert $Infile \
\( -clone 0 -roll +0+"$h2" \) \
+append \
-write mpr:sometile \
+delete \
-size 1224X1584 \
tile:mpr:sometile \
$Outfile
to create this staggered tiling (1224X1584 is the page size (8.5in x 11in) multiplied by 72 px/in, times 2 for a good density of tiles):
And here it is unwatermarked again
#ZachYoung I used some different image magic, also scriptable, the point is:-
Although "What's done cannot be undone" Macbeth (Act 5.1. 63-4) is very true especially within a PDF or image. We also know and expect that it too applies to any PDF (de)constructs. Thus depending on value of a forgery it will always be worth engineering a partially reversed copy, fit for scrutiny or use, but will like the watermarked copy, still not be the original, however all the same, may look almost just as good.
The Idiom implies don't bother yourself about it. Its best not done in the first place.
The nearest to best, is use a watermark exactly the same as the text outlines, like this:-
I have an image that I want to blur like on the iOS 7, see image below:
I'm not sure what combination of transformations I need to execute to get the same result. I tried something very basic so far (not sure what I'm doing), but the result isn't here:
convert {$filename} -filter Gaussian -define filter:sigma=2.5 \
-blur 0x40 {$newFilename}
The above code gets executed by php exec function.
If I take this as background.png
and a plain grey rgb(200,200,200) image with a couple of black and white bits and pieces on it, as foreground.png since I don't have any iPhone grabs of the slide-up menu thingy
convert background.png \
\( +clone -gravity south -crop 360x450+0+0 \
-filter Gaussian -define filter:sigma-2.5 -blur 0x40 \) \
-composite \
\( foreground.png -matte -channel a -fx "(u.r<0.1||u.r>0.9)?1:0.3" \) \
-composite result.png
So, I basically clone the background, and select the bottom part with the -crop and blur it, then composite it onto the real background. Then I take the foregound and anywhere it is not black or white, I set it to 30% transparent (so as not to fade the black and white aspects). Then I composite that ontop of the background which by now already has the lower part blurred.
It's probably not 100% but you can diddle around with the numbers and techniques till you achieve Apple-y perfection :-)
I'm trying to add the capability to render LaTeX equations to a project I'm working on. To do so, I use XeLaTeX to create a PDF file, which I then render to a (transparent) 96dpi-PNG using Ghostscript.
I'd like to have the rendered LaTeX blend in with the rest of the text (which is rendered using standard .NET GDI+ methods, but that's off-topic), but I can't get a reliably "good" text rendering: the output always looks somehow blurry or otherwise "bad".
Example:
From left to right, the same (small) PDF rendered at 96dpi with Ghostscript, Photoshop, and TexWorks (which I understand uses Ghostscript internally).
The command I use to run Ghostscript is the following:
"C:/Program Files (x86)/gs/gs9.09/bin/gswin32c.exe" \
-q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT \
-dMaxBitmap=500000000 -dAlignToPixels=1 -dGridFitTT=2 \
"-sDEVICE=pngalpha" -dTextAlphaBits=4 \
-dGraphicsAlphaBits=4 "-r96" -dFirstPage=1 -dLastPage=1 \
-sOutputFile="output.png" "input.pdf"
(which I actually pretty much copied from the command ImageMagick calls when converting a PDF file, but that's another story). I tried changing any of the relevant options (dAlignToPixels=0, dGridFitTT=0/1/2, dTextAlphaBits=2/4 [or without this parameter altogether]) and I even tried to render the PDF to 4 times the resolution and then downscale it, without any noticeable improvement.
Yet, I'm sure there must be some way of decently rendering the PDF with Ghostscript (since TexWorks does), although I'm unable to find it.
Any hint? The PDF is this one.
You could try to render your PDF at a higher resolution. 96dpi just isn't enough for text with 11 pt size.
If you use 192dpi and then scale the display of the resulting image to 50% (wherever you use the PNG), these parts should still appear in the same size as befor, but with a higher resolution. What used to be a 4x7 pixels 's' should now be a 8x14 pixels 's'...
Update
Ok, since my explanation seems to have been not comprehendible enough for the OP, here's the deal.
Generate a PDF file containing the word "Test", using Ghostscript. In my case, it is Ghostscript v9.10:
gs \
-o test.pdf \
-sDEVICE=pdfwrite \
-g230x100 \
-c "/Helvetica findfont \
11 scalefont \
setfont \
1 1 moveto \
(Test) show \
showpage"
From this PDF, generate 6 different images depicting the word "Test", using 6 different resolutions. The gs is still Ghostscript v9.10 (to be checked with gs -version):
for i in 1 2 3 4 5 6; do \
gs \
-o t$(( ${i} * 96 )).png \
-r$(( ${i} * 96 )) \
-sDEVICE=pngalpha \
-dAlignToPixels=1 \
-dGridFitTT=2 \
-dTextAlphaBits=4 \
-dGraphicsAlphaBits=4 \
t.pdf ; \
done
This will create the following PNGs, as confirmed by ImageMagick's identify command:
identify -format "%f : %Wx%H pixels -- %b filesize\n" t[1-9]*.png
t96.png : 31x13 pixels -- 475B filesize
t192.png : 61x27 pixels -- 774B filesize
t288.png : 92x40 pixels -- 1.1KB filesize
t384.png : 123x53 pixels -- 1.43KB filesize
t480.png : 153x67 pixels -- 1.76KB filesize
t576.png : 184x80 pixels -- 2.01KB filesize
Create a sample LaTeX document and embed the different images side by side and/or line by line. Here is my sample code:
\begin{document}
Test
\includegraphics[height=7.5pt]{t96.png}
\includegraphics[height=7.5pt]{t96.png}
\includegraphics[height=7.5pt]{t192.png}
\includegraphics[height=7.5pt]{t288.png}
\includegraphics[height=7.5pt]{t384.png}
\includegraphics[height=7.5pt]{t480.png}
\includegraphics[height=7.5pt]{t576.png}
Test\\
{}
Test <== real text
\includegraphics[height=7.5pt]{t96.png} <-- 96 dpi figure
\includegraphics[height=7.5pt]{t192.png} <-- 192 dpi figure
\includegraphics[height=7.5pt]{t288.png} <-- 288 dpi figure
\includegraphics[height=7.5pt]{t384.png} <-- 384 dpi figure
\includegraphics[height=7.5pt]{t480.png} <-- 480 dpi figure
\includegraphics[height=7.5pt]{t576.png} <-- 576 dpi figure
Test <== real text
\end{document}
Here is a screenshot (at 400% zoom) from the PDF created via LuaLaTeX from the above LaTeX code:
The line with the 8 "Test" words has actual text only in the first and the last word. The 6 words in between are images with 96, 96, 192, 288, 384, 480 and 576 dpi.
I hope you can see now clearly how scaling up your image generation to a higher resolution will result in better quality for your final PDF if you include the higher resolution images into your LaTeX code...
You are rendering text at 11 points, at 96 dpi, that works out to about 14 pixels in height which, frankly, is not a lot (and in my output the 's' is 7 pixels high by 4 wide). Looking at your output all 3 look 'blurry' and the Photoshop output looks overly bold in the capital T.
If you don't want it blurred, then don't set TextAlphaBits, or don't set it to such a high value.
I'd also suggest using the current release (9.15).
I have around 100 PDF files (each 1-3 pages long) that are formatted strangely, and I need to fix them. The problem is that there's a ton of white space at the top of almost all of them. I have Acrobat X Pro.
For example: http://imageshack.us/a/img195/510/ex1w.png
Download example: http://www.sendspace.com/file/2hohj5
I've tried selecting the text with the "Move or make changes to objects tool" and shifting it up, but there's a white box in the way that covers the text. If I delete the box, there's more text under it that I can't have.
I'm very confused. If this question isn't making sense please download the pdf and try for yourself.
Another example (across multiple pages this time): http://imageshack.us/a/img337/3714/ex2v.png
Download example: http://www.sendspace.com/file/q7dmnl
You can use Ghostscript to cut off content from pages and reduce the page height. Try this:
gs \
-o out.pdf \
-sDEVICE=pdfwrite \
-g6120x5000 \
2hohj5.pdf
Result of 1st page cropped (as PNG, scaled down):
Alternatively, you can use Ghostscript to shift the contents of each page up by, say 3 inches ( == 216 points) without changing the page sizes:
gs \
-o out2.pdf \
-sDEVICE=pdfwrite \
-c "<</Install {0 216 translate}>> setpagedevice" \
-f 2hohj5.pdf
Result of 1st page, content shifted upward by 3 inches (scaled PNG):
This is related to:
Converting PDF to CMYK (with identify recognizing CMYK).
Script (or some other means) to convert RGB to CMYK in PDF?
... but a bit more specific here: say I have an RGB PDF, where the text color is "rich black" (R:0 G:0 B:0 gone to C:100 M:100 Y:100 K:100), and diverse images and vector graphics.
I would like to convert this to a CMYK PDF, using a free command line tool (so it is batch scriptable under Linux), which
has contents only in the black (K) channel:
Preserves vector graphics (+ text glyphs) - colors become grayscale in black (K) channel only
Images get converted to grayscale in black (K) channel only
Thanks in advance for any answers,
Cheers!
As hinted in my comment to #Mark Storer, it turns out that forcing a gray print only on the K plate in CMYK, may not be so trivial ... I guess it depends much on what is being used as "preflight" preview device - for Linux, the only thing I can find is ghostscript with tiffsep, which is what I use for 'sanity check' regarding CMYK separations.
Anyways, I got a lot of help in this thread on comp.lang.postscript:
PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? - comp.lang.postscript | Google Groups
... and one workflow that works for me is:
Convert PDF to PS using ghostscript's ps2write
Use ghostscript to convert this PS back to PDF, while executing replacement functions in HackRGB-cmyk-inv.ps
Use ghostscript's tiffsep to check actual separations
In respect to, say, this PDF generated by OpenOffice: blah-slide.pdf, the command lines would be:
# PDF to PS using `ps2write` device of `ghostscript`
gs \
-dNOPAUSE \
-dBATCH \
-sDEVICE=ps2write \
-sOutputFile=./blah-slide-gsps2w.ps \
./blah-slide.pdf
# PS to PDF using replacement function in HackRGB-cmyk-inv.ps
gs \
-dNOPAUSE \
-dBATCH \
-sDEVICE=pdfwrite \
-sOutputFile=./blah-slide-hackRGB-cmyk-inv.pdf \
./HackRGB-cmyk-inv.ps \
./blah-slide-gsps2w.ps
# check separations
gs \
-dNOPAUSE \
-dBATCH \
-dSAFER \
-sDEVICE=tiffsep \
-dFirstPage=1 \
-dLastPage=1 \
-sOutputFile=p%02d.tif \
blah-slide-hackRGB-cmyk-inv.pdf \
\
&& eog p01.tif 2>/dev/null
This should only work on RGB values where R=G=B (and hopefully grayscale values), and only on text colors, and it also flattens text information - but it should be possible to confirm via tiffsep that the text indeed ends up only on the K plate.
As mentioned in the newsgroup post, this is not extensively tested, but looks promising so far...
Cheers!
As an improvement to sdaau's great answer, I can recommend using pdftops from xpdf for converting pdf to ps, instead of ghostscript ps2write, because the latter e.g. causes the font to become staircasey, and is said to not preserve the original pdf accurately. Compare by zooming into text areas of the resulting pdfs.
I suggest you convert the PDF using GS twice. Once to a Shades Of Gray colorspace, and then to CMYK.
I'm not sure it'll work, but I'd be a bit surprised if it didn't. G->CMYK sounds like a brain-dead X -> 0 0 0 X conversion. At least if you stick to "device gray" and "device CMYK" instead of some calibrated color space that'll tweak things this way and that.