This is an old question, but on Windows, on Mac and on Linux, you can extract images from PDF (without recompressions) with different multi-platform tools: 1) pdfcpu > pdfcpu extract -m image in.pdf . 2) pdfimages > pdfimages -all in.pdf page 3) mutool > mutool extract in.pdf 4) img2pdf, that has been already mentionner for Linux, exists also for Windows and MAC (it's a Python script).
This is an old question, but on Windows, on Mac and on Linux, you can extract images from PDF (without recompressions) with different multi-platform tools: 1) pdfcpu > pdfcpu extract -m image in.pdf . 2) pdfimages > pdfimages -all in.pdf page 3) mutool > mutool extract in.pdf 4) img2pdf, that has been already mentionner for Linux.
I would like to script the following action : 1) import multiple images from pattern (like page*.png) 2) convert all images to black ans white with threshold 700 3) save the resulting images in a single pdf (with ccitt compression) Is it possible to achieve this steps with the cli ? (I know how to do it with the GUI) Thanks in advance for your help.
I would like to advocate for this feature. PDF supports jpx (i.e. jpeg200 streams). And the quality of jpeg2000 for the same file size is much higher, compared to jpeg (even to files compressed with mozjpeg). You can check this assertion for exemple in this comparison page.
I would like to advocate for this feature. PDF supports jpx (i.e. jpeg200 streams). And the quality of jpeg2000 for the same file size is much higher, compared to jpeg (even to mozjpeg). You can check this assertion for exemple in this comparison page.
Use mozjpeg for jpeg compression
Correct bug #523 of pic text displacement in right angle
correct bug of pic text in right angle
Right angle text displacement
Orthogonal precision
You can also add the new tags vX.X.X and keep the old ones the time to decide to delete them.
The tags are here to make simple references to the past versions. If the tags do not follow some convention this do not make the task simpler. Another reason is that when you look at the tags at sourceforge they are badly ordered because they do not follow a naming convention.
Refactor the tgs
Done.
Correct bug #285
correct the bug #285
This is a problem at TikZ level only, conserning name path key (vs name path global key).
This is a paroblem at TikZ level only, conserning name path key (vs name path global key).
I think I have found a solution (or an idea of solution): instead of resetting globally \tikz@intersect@namedpaths after the ; we can do it at the beginning of every \path command. Here is the code : \let\tikz@installcommands@original\tikz@installcommands% \def\tikz@installcommands{% \tikz@installcommands@original% \let\path@original\path% \def\path{% \global\let\tikz@intersect@namedpaths=\pgfutil@empty% clear \tikz@intersect@namedpaths globally \path@original% } } And if this code is used we don't...
I think I have found a solution (or an idea of solution) : in place to reset globally \tikz@intersect@namedpaths after the ; we can do it at the beginning of every \path command. Here is the code : \let\tikz@installcommands@original\tikz@installcommands% \def\tikz@installcommands{% \tikz@installcommands@original% \let\path@original\path% \def\path{% \global\let\tikz@intersect@namedpaths=\pgfutil@empty% clear \tikz@intersect@namedpaths globally \path@original% } } And if this code is used we don't...
I think I have found a solution (or an idea of solution) : in place to reset globally \tikz@intersect@namedpaths after the ; we can do it at the beginning of every \path command. Here is the code : \let\tikz@installcommands@original\tikz@installcommands% \def\tikz@installcommands{% \tikz@installcommands@original% \let\path@original\path% \def\path{% \global\let\tikz@intersect@namedpaths=\pgfutil@empty% clear \tikz@intersect@namedpaths globally \path@original% } } And if this code is used we don't...
I think I have found a solution (or an idea of solution) : in place to reset globally \tikz@intersect@namedpaths after the ; we can do it at the beginning of every \path command. Here is the code : \let\tikz@installcommands@original\tikz@installcommands \def\tikz@installcommands{% \tikz@installcommands@original% \let\path@original\path% \def\path{% \global\let\tikz@intersect@namedpaths=\pgfutil@empty% clear \tikz@intersect@namedpaths globally \path@original% } } This works with the examples I have...
One more : I think that \global\let\tikz@intersect@namedpaths=\pgfutil@empty (with \gloabl !) should be executed rally "after" the ; if this is possible. The \tikz@finish is executed more than once for some "complex" paths, end this is why \gloabl breaks some examples. For example the following code, where I aded manually \clear@namedpaths after each ;, works fine. \documentclass[tikz,border=7pt]{standalone} \usetikzlibrary{intersections} \makeatletter \def\clear@namedpaths{\global\let\tikz@intersect@namedpaths=\pgfutil@empty}...
I was thinking to reset \tikz@intersect@namedpaths using \aftergroup. In the folowing example it works \documentclass[tikz,border=7pt]{standalone} \usetikzlibrary{intersections} \makeatletter \def\tikz@intersect@finish{% \ifx\tikz@intersect@namedpaths\pgfutil@empty% \else% \tikz@intersect@namedpaths% \gdef\temp{\let\tikz@intersect@namedpaths=\pgfutil@empty}% \aftergroup\temp% \fi% }% \begin{document} \begin{tikzpicture} \draw[help lines] (0,0) grid +(3,3); \draw[name path=a] (0, 1) -- +(3, 0) node[right,pos=1,sloped]{path...
Thanks. I hope that will be the end of this Ticket :)
The "new" line 1187 is not good. I have made another merge requaest. Let me explain : in the original version this line was \c@pgf@counta=\pgfutil@tempdimb\relax% and is used in a calculation to check from where to start the loop, because the first line is not necessarilly stratong from the starting point. But in this version at this moment \pgfutil@tempdimb has the same value as \pgf@xa, which is more natural to be used here. And when there is no nolinear transform \pgf@xa is also equa to \pgf@x....
Correct inconsistant behavior when ystep=0
correct a bug in grid operation when ystep=0
I made a new merge request with the modified line 1187. Now I partially remember why this line was changed : it is not a copy paste error. The original code was : \c@pgf@counta=\pgfutil@tempdimb\relax% but as \pgfutil@tempdimb is set to be \pgf@x in the \ifdim part for the y step I was thinking that if this code is not executed (in the case \pgf@yc is 0 for example) in place to set \c@pgf@counta from \pgfutil@tempdimb it should be set to \pgf@x ... I was wrong. To be honest I do not understand in...
Better grid operation : second attempt
correct bug in the grid operation introcuced by 0a65c101
The error comes from bad copy/paste in the code (I think) :( The faulty line is 1187 with the code \c@pgf@counta=\pgf@x\relax% This line should simply be deleted. The code is supposed to do only three things : check that the y step is positive ~~~ \ifdim \pgf@yc > .01pt\relax% if to draw horizontal lines ... \fi% ~~~ check that the x step is positive ~~~ \ifdim \pgf@xc > .01pt\relax% if to draw vertical lines ... \fi% ~~~ and move at the destination position at the end ~~~ \pgf@process{#3}% \pgf@pos@transform{\pgf@x}{\pgf@y}%...
I thnik that you can close this "bug". My comment about sqrt(1/2) is already integrated in the code. One remark, if you want to speed it up a little bit you can replace sqrt(1/2) by 0.7071067811865476, or something shorter ;) Thanks for considering my contribution !
If you want a "better" approximation for sin you can keep 0.31831 which is 1/pi but you can replace 0.63503 by 0.63662 which is 2/pi. And the corresponding values for cos are 0.36338 which is 1-2/pi and 0.68169 which is 1-1/pi. But it is not clear that this is a "better" approximation ... it depends how you define "better".
Add right angle to angles library
add right angle to angles library
Thanks for considering my merge request. It's nice to now that we can help the project we like.
Thanks for considering my merge request. It's nice to now that we can help the project that we like.
Thanks to considering my merge request. It's nice to now that we can help the project that we like.
Try to implement more consistent and stable grid operation
better grid operation (fix issue #484)
Better grid operation
Better parabola operation
The node position shold be corrected by factor of sqrt(1/2) in a way to have for angle eccentricity = 1 a coordinate on the angle vertex.
Add right angles to angles library
Better SVG path parser (future)
Dear Developpers, I want to advocate this ticket too. I know that passing from CSV...
I haven't seen the bug #304 when I posted this one. I think it is the same bug.
I havn't seen the bug #304 when I posted this one. I think it is the same bug.
This looks the same as the bug #339 (that is closed now).
In a strange way if you pass the gray option to xcolor directly there is no problem...
[turn] after plot in transformed scope fails
Here is a hacky solution : http://tex.stackexchange.com/a/211615/9335
node after pic is not working
\tikzexternalize with prefix containing ".." fails
Mistake in the explanation of cm transform
node scale and outer sep