I create a new part (not my first one): I draw the breadboard and save as SVG, build the new part - all OK. But if I draw a circuit with this part and export the work as a Image/PDF only this part will be a bitmap (with JPEG artifacts) in the PDF - the other parts are vector graphics. Why?
Upload the fzpz part file so we can have a look. Or the fzz file that you are exporting from.
First guess is that the svg file for the view has an embedded raster image.
Attached the original SVG and the part. I check it with Inkscape but can not find any raster image
ADXL345.fzpz (58.0 KB)
It looks like more information is needed. I found several problems with the part for normal use (it appears you are only working with breadboard view, and doing it quite correctly), but I was able to place it in a sketch, export the breadboard view as Image / PDF, and get good results. Here is my test sketch and exported pdf.The ADXL345 part looks fine in the pdf using my viewer program (Foxit Reader).
What version of Fritzing, and what operating system are you using? My test were done using Fedora 33 and Fritzing 0.9.6. Does the pdf file I created look good in your environment?
ADSL345_test.fzz (90.4 KB)
The forum does not allow uploading pdf files, so I renamed it to add .fzz to the end. Download, then rename to remove the “.fzz” to view it.
ADXL345_bb.pdf.fzz (559.7 KB)
Thank you for your help.
Yes, I only use breadboard parts (IMHO are the other views useless) and I only need the breadboard parts for my job
It’s interesting: Your PDF is well formattet. But there is a small mistake: I mark it in ADSL345_test_Steckplatine.pdf. The transistors are “broken” (?)
I remove the transistors for testing but it does not help.
Attached a PDF exportet by me: raster image of my part
I use Win 10 64 Bit with actual version (German): Version 0.9.6 (bCD-175-0-8a1e0682 2021-02-21) 64 [Qt 5.12.10]
test.zip.fzz (1.1 MB)
As a data point here is a pdf export of breadboard of your adxl345.fzz file on Windows10 and Fritzing 0.9.6. I don’t know how to determine if the pdf is a bitmap or not, it looks like the image in Fritzing (and your bitmap example in your zip file to me!) I do see that your adxl345_Steckplatine-arduino.pdf file here (rendered in firefox):
lacks the green connected dots on the connectors which are present on mine, so the pdfs are different
here is a zipped copy of my pdf output in case it helps to tell if it has the undesired bitmap.
adxl345_bb.zip.fzz (349.3 KB)
edit: perhaps your pdf renderer? This is your pdf at 1000% scale (as far as firefox will go) it is slightly pixelated on the red servo pin but not much
this is my pdf output at the same %1000 scale slightly less pixelated
may be a graphic card resolution issue though. I’m running 1920 x 1080 screen resolution.
Peter
The red wire is interesting (but maybe the problem of the fritzing-guys)
The pixels and JPEG errors are shown in Adobe Reader and Illustrator.
I change the color for connections from green to gray because I did not like it and did not want to see it (wish: an option to disable this function)
Screenshot with Adobe Reader:
The danger in that is that Fritzing will sometimes not make connections correctly (leaving the connection red as an indication of no connection) so you can have an image that appears correct but is missing expected connections. We see a fair number of sketches from new users with this problem.
To me this looks like an artifact of the conversion from vector to bitmap. Depending on what the output resolution is when Reader or Illustrator renders the pdf it has to change it from vector to raster because all the displays I know of are raster and I think (but don’t really know), that pdf is vector which should maintain the resolution.
Peter
I use fritzing only as a graphic tool for illustrating in a printed magazin - I can use any graphic tool but some functions are helpful. so for me the green marks are ugly.
And what is the benefit? If it looks like a connection and someone rebuild the image it is a connection. Remember: shematic and PCB are IMHO a really waste implementation (for example: it’s a software created by Germans but use international wrong images 
for GND, VCC, resistors, connections and so on) and no one should use it.
EasyEDA is much better, easy to learn and they implement correct images in very short time after I told them. 
I did not understand this. Where is the conversion from bitmap to vector? If I make a screenshot of a vector image it looks like a vector image: no jpeg artefacts and sharp fonts etc. I draw a vector image in Inkscape (reusing other parts if possible) and in most cases the result will work. Only in this case (and some others) not.
I think it’s a problem of the conversion routine in fritzing. Because made with Linux it works (but have the problem with the transistor) and with Windows it will not. I do not know how it was coded (and will not know).
Wrong direction. The conversion is from vector (svg or pdf) to raster. Most modern computer displays are raster (i.e. bit mapped) so to display a vector image such as a svg or pdf they need to convert the image from vector to raster. That conversion by definition causes pixelization, which will show up if zoomed in enough. In this case something in the conversion (which is outside of Fritzing I expect) is using a lower DPI (dots per inch) value to do the conversion. That shows up as pixelization in the image. I’m not enough of an expert at graphics output drivers to tell you where this is occurring but as noted I don’t think it is in Fritzing. You should be able to verify that by exporting the image as svg (instead of pdf) and examining it in Inkscape. I would expect the pixelization to not be present there because the export is svg and thus vector, the conversion to raster takes place in Inkscape not Fritzing. I don’t know how a pdf is coded internally but I expect it is also using vector and only converts to raster for output.
Peter
pdf supports embeded bitmap (raster) images. It may also work with vector. I do know know. My previous experience, based on what did and did not export, is that Fritzing pdf export is really a jpeg export that is then wrapped in a pdf. pdf is really (mostly) a wrapper structure, just as zip is. So pixelation and artifacts in the pdf exports are likely to be the same as in jpeg exports. That does not explain why some parts are different than others in the same export.
That experience is from parts that fail to export to svg due to missing breadboard id, do export to both jpeg and pdf. I have used tools that allow extracting images from pdf, and get jpeg. I have never found one (limited sample set) that exported to a vector image.
Ah! I didn’t know that. I have used pdfs but never looked at the details of generating one. In that case the best thing to try would likely be doing the export from Fritzing as an svg to maintain vector output and see if Illustrator will convert the svg to a better quality pdf. A quick look indicates Inkscape doesn’t have an obvious pdf export (there may be a plug in for it though.)
edit a quick google search tells me I wasn’t looking in the correct place:
Convert SVG to PDF in Inkscape
- Open Inkscape and click File->Open to load the file for conversion .
- Click File then Print or press Ctrl+P and in the Print window select novaPDF as the printer.
- Click on Print and the SVG will be saved as PDF .
This may do a better job than Fritzing (or may not 
)
Peter
This workaround was my first try. Normally I work with SVG and not PDF for my work. But SVG export has much more problems in fritzing than PDF so I must switch over to PDF.
- sometimes there are parts completely missing (I have no example in this moment). I think it is a problem of the part and there is no ID “breadboard”
- other strange things I did not remember
I try it with the adxl345 from above:
This is the SVG saved by fritzing: 
This is a screenshot of Inkscape (just opened):
Letters are missing. wrong font on Arduino. But all vector
In Firefox it will be rendered the same way (only other font on Arduino)
And last and least AI:
Wrong font and surprise: where are the parts? (some are at the bottm some are between the black and green wire) 
In my opinion fritzing build the errors because why a vector program should delete some letters (they are created as paths to bypass the problem with wrong fonts).
I think: every vector program has many issues and no format is the best. There is only one process that causes the fewest errors for each individual. Sometimes I miss BMP.
A known problem. Many of the part creators only check what the part looks like in Fritzing. They do not test the SVG export and several other things. We are slowly trying to fix them. If the id is missing the part does not export to SVG (or to gerber). If the id exists, but some parts of the graphics are outside of the layer, those graphics do not get exported.
One of the missing id cases is (from a few samples) parts that were created using eagle2frtizing. It may not include the layer for breadboard. Converted parts need to be cleaned up, and that often does not happen.
Fritzing has specific fonts that it supports. If the parts are not created with those fonts, you can expect problems. Turning the text to vector outlines is not a “good” solution. It makes the part files (a lot) bigger, and makes any future editing a harder.
I know. Some time before I try it with the two fonts and I have problems (not remember what kind). So I use paths and accept that I must enter the text again if it must be. And the problem is going on: As you can see the wrong font is used on the Arduino shield by Inkscape although I have the fonts. 
Maybe I can solve problems like this but this is not my job and as a solution I use an other way…
The missing text in your part is a Fritzing bug (fixed in 0.9.7) as the path uses scientific notation which currently breaks Fritzing export.
replacing the 6.9e-4 with 0.00069 in the breadboard svg of the part (probably with a text editor to prevent Inkscape from using e notation again) will fix it as a work around. Using fonts instead of a path will also do the job. I don’t see the problem with the Arduino font, it is OCRA the same as in the Fritzing part. For Illustrator, it appears (since Inkscape can render it correctly) there is an Illustrator issue (possibly transforms from what is happening.) I don’t have Illustrator so can’t test to see what it is objecting to. I think Illustrator needs the space:preserve directive (which Inkscape doesn’t) in the svgs but I don’t know if that is what is causing this.
Peter
It’s nice to know but really? I can not go through more than 50 exported files to find and correct errors. And it’s only one example. The missing “breadboard” issue is in other files.
No: Inkscape and AI did not render the OCR font on the Arduino board. It is Arial or something else. If not even the pictures/parts from fritzing are rendered correctly what should a normal guy can do?
But it is as it is. The original problem was the raster image instead of vector and meanwhile we discuss numberless problems. I’m the first one who cares it?
You could, but it may not be efficient. So your choices are: fall back to Fritzing 0.9.4 as I believe the path bug was introduced in 0.9.6, or compile 0.9.7 from source and run that (what I would do), or fix your part once manually, which should correct all instances of it with a reload or wait for 0.9.7 to be released. None of these are ideal, but they are what we have.
This one is not a Fritzing bug, it is a misconfigured part. It is also easy to fix in the part (as all parts have their source in the .fzpz file) by unzipping the .fzpz and either running FritizngCheckPart.py and fixing the things it flags as errors (which usually will break Fritzing) or in this particular case edit the breadboard svg in Inkscape or Illustrator, do (in Inkscape, I don’t know Illustrator) Edit–>select all group and name the resulting group to the appropriate layerId (breadboard in your case usually, or whatever is used as the layerId in the .fzp file.) then rebuild the .fzpz file with the new breadboard svg. That corrects the part for all future use. Eventually once I finish an updated version of FritzingCheckPart which is taking a long time, I will go through an clean up all the parts in core parts (many of which are broken.) Since I’m the only one so far willing to do it, that will take a bunch of time.
Not for me in Inkscape (couldn’t say about Illustrator.) This is a recreation of your sketch with the breadboard exported as svg:
Note AREF is OCRA 3.75px font-size. This is the breadboard svg for the Arduino Uno R3 part
Also OCRA 3.75px font-size. Appears to be identical to me as it should be, so I don’t see a problem nor any Ariel or other font in use.
You are the first I know of to complain about the rasterization on pdf export, but there have been lots of complaints about lots of issues (including pdf export) in Fritzing. What there hasn’t been is anyone interested in doing anything about fixing any of them (which is I will admit hard to do.) Fritzing development died for 4 or 5 years only resuming in 2020 after stopping in 2016 or earlier. The way forward is seen as paid professional developers (funded by the pay wall) as the code base is concidered to complex for volunteer effort (and the lack of many fixes being submitted by the community backs that up!) I tried to restart development starting in late 2016 without any success (lots of complaints, no one willing to commit any time or fixes.) The Aisler folks (who run the fab) are responsible for getting development restarted. There is still almost no community involvement in providing fixes. We can often suggest work arounds to known problems such as the above. With development restarted we can even make (and have been making) progress on bug fixes, but it is going to be slow. Most of a year or more was spent on doing maintenance on the web site and rebuilding the build system which was largely invisible to the community. Now bug fixes and improvements (i.e. 0.9.6 and 0.9.7) are starting to happen if slowly.
Peter
Creepy. Maybe it’s a problem with my font installation (Windows). I have some problems to say Inkscape what fonts are installed (it’s a known problem). But AI? And I remember that I have the problem on an other System.
Well.
I know it with the long pause. The pay wall is IMHO a pain in the ass. You will lost many new users. Fritzing was freeware and freeware is free developed by volunteers who like to do it.
I did not like to program in a group and never with a Git. So I publish my parts (only breadboard view) for free and get no money for it too. That’s the way freeware works.