I'm trying to edit a vector graphics file from Freepik. The format is EPS and after installing both Inkscape and Ghostscript on Windows, I'm able to open the file with Inkscape. However, Inkscape introduces some weird artifacts (see lines and wrong colors in the picture below).
Side by side comparison, original vector (left) and SVG saved after opening the EPS file in Inkscape (right)
Is there a way to fix this issue?
It's a little difficult to tell, partly because this is a complex illustration and partly because the rendering is a little small. I'd suggest that the circular artefacts are caused by radial fills not being rendered completely.
This could simply be a rendering problem with Inkscape, or it could be that the radial fill has an Extend parameter which isn't being honoured. It could also be a problem calculating a clip.
It's not entirely obvious what you used to render the left hand image, is that Ghostscript ?
Generally I'd say this looks like an Inkscape bug and you should report it as such.
Edit
Reading through the Inkscape FAQ it seems that Inkscape uses SVG as its native format. That's going to mean that an awful lot of PostScript (and PDF) vector objects aren't going to be represented well. Shadings will either have to be rendered to an image or converted into a complex series of SVG primitives.
Following the link on 'How to open EPS files in Windows' from the FAQ suggests to me that EPS files are either rendered to an image or converted to PDF.
You could use Ghostscript to convert the EPS to PDF yourself, and then try loading the PDF into Inkscape to see if you get a better result. You can also open the PDF in, say, Acrobat to see if it looks OK there.
If the PDF looks fine in Acrobat, but not so good in Inkscape, then I'd say that's an Inkscape problem. If the PDF looks poor in Acrobat then that's a Ghostscript problem.
You can then report the problem as a bug to the appropriate site.
It seems that EPS has more capabilities than SVG and that's why some stuff looks weird when converted to PDF/SVG. Specifically, highlights in an EPS file are not properly rendered in an SVG file.
I checked the conversion from EPS to PDF via Ghostscript and the lines are already there, i.e. it's not an Inkscape bug.
Here's the original file to reproduce the problem:
https://www.freepik.com/free-vector/data-processing-factory-isometric-technology_8625296.htm
And here's what it looks like after converting it to PDF: The artifacts are not as noticeable on the PDF file, possibly because Ghostscript converts it with a higher DPI by default
My workaround to be able to edit the file (remove the background) was to:
open the EPS with Inkscape, ungroup the items
delete the background
export it as PNG
then use the PNG as a "mask" on GIMP to edit the JPG file that came together with the EPS.
Related
I want to automate "raster to vector" conversions. PNG to SVG. (most Qs here on SO are the other way around)
I have tried the old command line tool autotrace on Linux, but I could not get it to run. I've tried to install a package, and to compile it from the source. Nope.
Then I've realised that Inkscape has "autotrace" now integrated in its codebase. I'd like to convert simple sketches from PNG to SVG.
And I want to do this in a Bash for-loop , with different autotrace settings (number of passes; ignore Speckles with max X pixels width) etc.
I've tried the "action" command-line option
inkscape --without-gui --actions="file-open:my.png"
and this brings up the small "png bitmap image import" dialog, waiting for me to confirm.
Also I've tried the verb command line option
inkscape --with-gui --verb="FileImport:my.png"
and this opens the large "Select file to import" dialog (ignoring my --verb argument)
At this point I gave up.
I want Inkscape to import a PNG picture, autotrace it with some settings, save it as SVG. Perhaps, beofre saving, duplicate the traced layer, lock the imported background layer, rename the layers from path-12345 to "tracesettings-x-y-z" etc.
(my final goal is to permute the tracing settings, to find good ones for my use-case, but that's not the focus of this question)
Inkscape is using potrace and autotrace to trace bitmap images into vector formats such as SVG and PDF.
Let's assume you have an image: foo.png that you want to trace to SVG using potrace:
First, you need to convert your image to a bitmap format (BMP).
Invoke the potrace command
# I am using ImageMagick convert command to convert PNG to BMP
convert foo.png foo.bmp
# Invoke potrace command with SVG backend
potrace -b svg foo.bmp
The result will be: foo.svg.
I'm trying to convert an eps (created with Mathtype) to svg format.
I don't have any problems with math characteres, but I'm unable to get any special characters (aka àâä...)
I have tried on unix and windows, and none of those works.
The font used is Arial, and is installed properly(Default on Windows, manually added in fonts folder in unix)
I have oppened the Arial font in windows font manager and the non working character are in.
They just aren't converted.
Actually, to convert I use Inkscape (with ghostscript) like this :
inkscape -z -f in.eps -l out.svg
Thanks in advance,
Edit :
Added in.eps file
https://pastebin.com/vBtUVy69
The fact that you have installed Arial on your Windows box has little to do with the problem.
Does the EPS file include the embedded Arial font ? If not then you are dependent on font substitution. You should probably post a sample EPS file so that we can look at it.
My guess is that the Arial font is not embedded, so Ghostscript substittues Helvetica, and the Helvetica font doesn't have those glyphs, or they are not encoded at the character codes which the EPS file thinks they are.
[EDIT]
The EPS comments say DocumentNeededFonts: Arial-BoldMT", so the EPS does not include the font and you get font substitution.
I can't tell you immediately why the SVG says Arial. I can guess, but in the absence of a complete description as to how you are producing the SVG I can't (obviously) be sure.
Now... if the conversion path uses Ghostscript's pdfwrite device to create a PDF file from the EPS, and that PDF file is then somehow converted to Inkscape's internal format (or directly to SVG using something other than Ghostscript) then what is happening is that Ghostscript is substituting Helvetica for the missing Arial-BoldMT and when it produces the PDF file it embeds the Helvetica font, but calls it Arial-BoldMT (or whatever). That's a consequence of the font substitution, the font that gets substituted gets renamed to the expected name.
I think you can avoid that by setting -dEmbedAllFonts to false, though I haven't tested it. Even if you do, all that happens is that the PDF file then doesn't have the font, just the same as the EPS file. So the SVG creation will (presumably) have to use a substitute font instead. All you do is shove the problem further down.
The correct answer to this is 'always embed fonts'.
You can also make the Arial-BoldMT font available to Ghostscript by editing its fontmap.GS file in ghostpdl/Resource/Init for builds where the resources are not built into a ROM file system. For builds which do use a ROM file system (eg Windows) you must pick up a copy of the Resources (from the Ghostscript Git repository), modify the fontmap.GS file and then tell Ghostscript to use the modified resources by pointing to it with the -I switch.
This is still a hack, because its a TrueType font being used as a replacement for a PostScript font, so there's a certain amount of guesswork going on inside Ghostscript, but it usually works well enough, YMMV.
I have tried nearly every library to convert pdf to svg, Following are the results of them
gs or ghostscript and imagemagick: The size gets multiplied by 100
pdf2svg and inkscape: The image on the top of the pdf is not at all accurate here are the links to the pdf and the svg.
PDF: https://drive.google.com/open?id=0BxyQR1owWa_pcnhhSk5wQWJGMVk
SVG: https://drive.google.com/open?id=0BxyQR1owWa_pVnhoLVlob1U2d1k
Please suggest me if I am missing something that needs to be done.
The Ghostscript SVG output device is seriously deprecated and no longer supported (or indeed built into the standard Ghostscript binary).
In any event, you need to be aware that PDF is a very rich graphics model, and it is simply not possible to reproduce every possible nuance of a PDF using the SVG graphics model, in particular fonts are a problem, but so is almost any kind of transparency. When that occurs Ghostscript will render the PDF to an image, and insert that into an SVG file. Almost certainly that's why you are seeing the SVG file being considerably larger than the PDF file. You should be able to use the -r switch to control the resolution of the rendering, allowing you to trade off quality for size.
Even if the whole file isn't converted to a bitmap, its possible that large portions of it are, or that the bitmap compression in SVG is less good than for PDF (or GS isn't taking advantage of all the possibilities). FWIW the PDF file uncompressed runs to > 4MB.
I've been doing some stuff in Illustrator and I have a problem with saving a project in to SVG file that I open in webbrowser, It just looks different.
And it hapens only in SVG, if I save it to PDF or PNG it looks how it should.
What am I doing wrong?
That's how it looks in Ai
That's how it looks in webbrowser
Here's a link to download rar file with .ai and .svg that I have.
Since all browsers render it the same way, it would seem likely that this is a bug in the AI SVG export filter.
To me it looks like you are applying a blend mode ("Overlay" perhaps?) to the white parts on top of the image. That effect ought to be reproducible using SVG filters, but perhaps AI's exporter doesn't support that yet.
If you are using an "odd" blend mode, try changing it, or reproducing the effect another way.
Individual pixel control needed in identical svg conversion is not possible. SVG creates only specific shapes. The Ai app conversion seems to use opacity to provide the color shades. You could probably tweek opacity and add some svg filters to improve the svg.
Print your design in a . pdf file instead of exporting it directly. Then open the printed .pdf back in Illustrator and export the .svg from this one, it shoud do the trick.
I'm creating a pdf with Apache FOP in Linux
then I need to convert the pdf it into an eps.
I'm trying lot of ways, the only one that seems works is the pdftops.
But,
when I convert it into Linux in command line
pdftops file.pdf -eps file.eps
This command creates me the eps
but when I try to open it in Adobe Illustrator in Windows XP
It returns me the error
EAAFD+HelveticaNeueLTStd-MdCnO_99-Identify-H;
Font not found on the system; missing font has been substituted.
But
1: the fonts han not been substituted
2: the eps do not show words inside it is all blank instead of the images
I'm sure that in Windows XP I have all the fonts
becouse if I convert the pdf to an eps inside the Adobe Illustrator
all works fine and Adobe Illustrator do not show me the fonts issue.
Can you help me?
What I'm doing wrong?
If something is not working as intended, then that's a bug clear and simple: it needs to be debugged and fixed. Please could you file a bug-report at:
launchpad.net/ubuntu/+source/poppler/+filebug
along with a copy of the PDF file that is being generated, and the exact command that is being used for the conversion (particularly whether it is pdf2ps (part of GhostScript), or pdfteps (part of Poppler/Xpdf and found in the poppler-utils package).
(Note that this question has been asked in three other places, but not yet reported in the bug-tracker where it can be explored, pointed to the right people and hopefully fixed).
Without knowing much about your setup, it looks like you're asking FOP to draw your text using the Helvetica Neue font, which is not part of the standard set of PDF fonts (note that Helvetica is, but not Helvetica Neue).
It would seem to me that your two options are to either force FOP to use Helvetica instead of Helvetica Neue, or force it to embed Helvetica Neue into the PDF (pdf2ps should automatically embed it into the result EPS file). In the first instance, you shouldn't need embedding at all, while in the second case the file should be embedded.
More info on how FOP handles fonts is also available from the package's documentation—as you can see, Helvetica Neue is not listed here.