In reality, I detected the original problem when using Inkscape 0.91 - it has an option to render Latex images on an SVG surface. Digging a little, it seems that the problem is due to pstoedit failing, which, when called separately reports:
$ pstoedit -f svg test.ps test.svg
pstoedit: version 3.70 / DLL interface 108 (built: Sep 25 2017 - release build - g++ 4.9.3 - 64-bit) : Copyright (C) 1993 - 2014 Wolfgang Glunz
Unsupported output format svg
Digging still deeper, it seems that pstoedit uses plotutils to do the work, but, from tests, plotutils seems to do what it is supposed to do:
echo 0 0 1 1 2 0 | spline | graph > test.meta
succesfully creates a test.meta file with a spline in it, while
plot -T svg test.meta > test.svg
converts that metafile correctly to test.svg
Versions installed are:
plotutls 2.6 (seems Ok, creates svg)
pstoedit 3.7 (works, except for svg)
Inkscape 0.91 (Latex appears in the extensions | render menu
but doesn't work - because pstoedit doesn't generate
the required svg)
I've also reviewed the ./configure options to check if something was missing - no luck.
Distribution is Slackware64-current. As Slackware always installs the header files, no header files (-dev, -devel...) are missing here (I've checked too. And recompiled pstoedit after installing plotutils)
Digging even deeper, I found the reason for the problem. Slackware64 installs libraries to /usr/lib64, so the the pstoedit plugins were installed in /usr/lib64/pstoedit. But it seems that pstoedit does NOT look in that directory when trying to load the plugins at runtime - it looks for /usr/lib/pstoedit instead.
It then reports supporting several formats except svg - giving the impression it did find some plugins. In a Debian bug report I found that the reporter checked the plugin search using the -verbose command line option, which doesn't exit (it's just -v)
Anyway, I solved the issue (for the moment) by making a symlink from /usr/lib/pstoedit to /usr/lib64/pstoedit. I'll send a report to the program author too.
Related
I am running debian buster on the docker image. I have installed every poppler package to rule anything unusual out. I have explicitly added the paths to all of the poppler files, containing directories, etc.
I have followed the documentation available on the pdf2image website here: https://pdf2image.readthedocs.io/en/latest/installation.html#
And have confirmed that poppler is installed and on the path with the recommended method:
root#1018c6c180a9:/# pdftoppm -h
pdftoppm version 0.71.0
Copyright 2005-2018 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
Usage: pdftoppm [options] [PDF-file [PPM-file-prefix]]
-f <int> : first page to print
-l <int> : last page to print
-o : print only odd pages
-e : print only even pages
...
And I get the following error when running in a docker image:
pdf2image.exceptions.PDFInfoNotInstalledError: Unable to get page count. Is poppler installed and in PATH?
I still assume I have made the mistake. But, it seems like the results that pop up on a search indicate that this is somewhat unresolved, with working scenarios achieved for some, but not all, users of the poppler library and python package pdf2image.
I don't have constraints on the debian image I use, or the pdf2image version, per say.
Is there a working configuration out there, is this issue resolved, or is there a hot spot for mistakes where everyone seems to have a similar problem (and I have fallen into the same trap)?
python3 vers 3.8
I'm trying to convert DXF files (from Fusion360) to plain SVG files using the Inkscape CLI. It works fine with one small annoyance: the Inkscape GUI promps me on how to read the dxf file (the settings in there are fine, all I do is click ok).
It's the same dialog you get when importing a dxf file through the Gui.
The command I'm running:
/Applications/Inkscape.app/Contents/Resources/bin/inkscape -z -l <absolutePath>/output.svg <absolutePath>/input.dxf
I've also tried this with no success with regard to the dialog popup:
/Applications/Inkscape.app/Contents/Resources/bin/inkscape -z -f <absolutePath>/input.dxf -l <absolutePath>/output.svg
-z means no GUI. Which works in terms of no Inkscape instance starting (XQuartz is starting though), but the pesky dialog can just assume ok and move on rather than checking with me for an ok click.
To be clear, the actual export is just fine. It's only the Gui dialog that's crashing my CLI-high :)
In short: any chance on flagging that dialog to go ahead without actual interaction from my part?
Specs:
MacOS 10.13.
Inkscape 0.91
I'm trying to use pcregrep as specified in the top answer to this SO question on Cygwin. My environment is Win7 64bit running Cygwin V 1.7.20(0.266/5/3).
Using cygcheck -p pcregrep I get:
Found 6 matches for pcregrep
libpcre-devel-8.37-1 - libpcre-devel: Perl Compatible Regular Expressions library development (installed binaries and support files)
libpcre-devel-8.37-2 - libpcre-devel: Perl Compatible Regular Expressions library development (installed binaries and support files)
pcre-debuginfo-8.37-1 - pcre-debuginfo: Debug info for pcre (installed binaries and support files)
pcre-debuginfo-8.37-2 - pcre-debuginfo: Debug info for pcre (installed binaries and support files)
pcre-8.37-1 - pcre: Perl Compatible Regular Expressions utilities (installed binaries and support files)
pcre-8.37-2 - pcre: Perl Compatible Regular Expressions utilities (installed binaries and support files)
I've tried using the instructions for installing pcregrep found in this tutorial, but patch doesn't seem to be part of the cygwin install. This tutorial was found through these two SO questions along the same lines as mine:
SO Question 1 and SO Question 2, citing them so they show up in the related questions section. This man page shows that it can exist in cygwin, but trying to run the man page for it results in:
$ man pcregrep
No manual entry for pcregrep
It appears that the libraries for pcregrep exist in my cygwin install, but I don't know how to compile / extract / enable them to gain access to the utility. When I try to run it, I get the standard command not found response from bash:
$ pcregrep
-bash: pcregrep: command not found
So my question is: What do I do in cygwin to allow me to use pcregrep?
I'm not sure how to proceed, I've got tens of thousands of log files to process and I need to be able to find three lines that are related to each by the number of lines in between two of them, the makeup of the strings in those lines and a "header" line above them that tells me that the correct sensor type information follows (there can be multiple sensor data in a single log and I have to use a specific set of sensor data). If I can't figure out how to install pcregrep (which seems perfectly suited for the job), I'll ask the underlying question with data.
Your cygcheck -p query indicates that pcregrep is mentioned in those three packages. The online package browser confirms that a pcregrep.exe binary is available in the pcre package: you don't have to compile anything.
Use the Cygwin installer, setup-x86.exe (for a 32-bit Cygwin) or setup-x86_64.exe (for a 64-bit Cygwin), which you've probably used to install Cygwin in the first place, to install the package: when you get to the "Select Packages" step, find pcre in the Text category, click the cycle icon in the New column until a version number appears, and finish the installation. If you no longer have the installer, you can download it from https://cygwin.com/.
Hello fellow Stackers,
Currently I am working on a website which requires the ability to handle, manipulate, create and save PostScript encoded files. Research on the topic pointed me towards two PHP classes called Imagick and MagickWand – both of which use Image Magick, which in turn depends on Ghostscript. Unfortunately the GD PHP class is not up to the task.
I am performing the installation processes on a server running GNU/Linux via SSH from my Mac with OS X 10.9.1. Any help would be much appreciated. If any other details are needed, please inform me and I will do my absolute best to provide them.
Thus far, I have managed to make Image Magick and Ghostscript function independently – while simultaneously installed on the same system. However I was not able to install Ghostscript accordingly for it to function as an Image Magick delegate. From Terminal I was able to run the convert and gs commands successfully. At the time I was able to use the Imagick PHP class to perform the required tasks – such as detecting Color Space – on rasterised images.
As it stands Image Magick has been uninstalled from the server. I was not able to uninstall Ghostscript correctly. So my first question is: how on earth do I uninstall Ghostscript 9.10? It seems Ghostscript does not include an uninstall in its Makefile, ie: make uninstall returns make: *** No rule to make target 'uninstall'. Stop..
I have done some research and it seems that I should have compiled the Ghostscript shared library first: http://www.linuxfromscratch.org/blfs/view/svn/pst/gs.html
Naturally I attempted to perform the steps in the article on Linux from Scratch. I have removed expat, freetype, lcms2, jpeg and libpng. I have performed ./configure with the suggested commands. I have also performed make and make so, both of which fail and exit, returning:
pngrutil.c:(.text+0x3cb): undefined reference to 'inflateReset2'
collect2: ld returned 1 exit status
make: *** [bin/gs] Error 1.
edit: I have since narrowed this down to be related to Zlib.
I am looking for either an alternative to Imagick and MagickWand (which I was not able to find), insights into what is going wrong during the installation process or what might be done to resolve the current error.
Thank you all in advance.
A manual process to uninstall may be required if there is no uninstall defined for the makefile.
This has been discussed in the question What's the opposite of 'make install', ie. how do you uninstall a library in Linux?.
I ditched the idea of using Ghostscript as an Image Magick Delegate, not only because the installation process was not working out for but, but also due to the fact that my research taught me that Image Magick rasterises all input files.
Instead I used the PHP exec() function to directly execute Ghostscript.
ALSO POSTED HERE i was not aware for tex.stackexchange before i made this post, so sorry for the double/cross post here is the link to the other tex.stackexchange post
https://tex.stackexchange.com/questions/153949/linuxnew-to-latex-path-to-latex-is-resetting-every-time-exit-the-terminal
I am trying to learn latex and i am running linux mint 15 x64. I have installed "texlive" and followed this installation guide:
http://www.tug.org/texlive/quickinstall.html
The problem i am having is, as the title suggests when i set my PATH variable to the latex directory, it works fine for one terminal window only, if i exit that terminal window the PATH no longer points to the latex install, thus i have to reset it every time which is rather annoying.
I am using the following command:
PATH=/usr/local/texlive/2013/bin/x86_64-linux/:$PATH
then when i do:
echo $PATH i get this result:
/usr/local/texlive/2013/bin/x86_64-linux/:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
and i can do this:
latex --version
pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013)
kpathsea version 6.1.1
Copyright 2013 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
There is NO warranty. Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
Compiled with libpng 1.5.16; using libpng 1.5.16
Compiled with zlib 1.2.7; using zlib 1.2.7
Compiled with xpdf version 3.03
which is as expected, but when i close the terminal window, and re open it i get the following:
echo $PATH
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <--- missing the latex path
and when i check the version:
latex --version:
The program 'latex' is currently not installed. You can install it by typing:
sudo apt-get install texlive-latex-base
i have also tried doing the same as the super-user, i get the same end product.
Any have a solution to this problem?
Thanks,
Chris.
Set the path in the .bashrc file or .bash_profile
Adding
export PATH=/usr/local/texlive/2013/bin/x86_64-linux/:$PATH
I'm pretty sure that putting
PATH=/usr/local/texlive/2013/bin/x86_64-linux/:$PATH
in your .bashrc will accomplish what you want