OCR A font not accepted (solved)

When I tried to use the font OCRA in SVG for breadboard view I get the error
“Fritzing unterstützt derzeit nur OCRA und Droid-Schriftarten–diese haben die Schriftarten in ‘D:/daten/fritzing teile/w5500_module_breadboard.svg’ ersetzt”

I used OCR A Std Regular.ttf which is wrong, one has to use the OCRA from the download site :wink:

Got the same issue. The topic title indicates the issue as solved - but I could not see any replies, not to mention solutions. What am I missing?

The download is available here:


the fonts are in the zip file and you need to execute them to load them in to your machine (at least on Windows).


Thanks for the reply!

Sure I’ve done that, just use Mac OS (my svg editing software recognises the font and I have it displayed properly). But I guess, svg file just specifies font name without embedding it, or am I mistaken? I have even tried to test svg import with one of the svg template files, provided on the Fritzing website - and I am getting the same result.

If you upload the svg file (7th button from the left on the reply tool bar, but you probably need to rename the .svg to .fzp and upload that because the forum often dislikes svg files) and I’ll have a look at it. Its possible they misspelled the font name in the svg (the Sparkfun part I’m working on in the other thread did this among its other sins). Fritzing will usually sub the font but it is better to have it correct.


I’ll do that in a few moments. Just wanted to point out that I use Boxy SVG, which also allows editing svg code directly, which I have checked and couldn’t find anything wrong with the font name. Just maybe Boxy SVG uses some different syntax, which confuses Fritzing part editor (although in that case the Fritzing provided templates should be imported properly - BTW, I have noticed that ocra10 but not OCRA font name is used in those templates).

Unfortunately the templates are out of date (someone else tried to use one lately). I have it on my long list of things that need doing, but its no where near the top. I may post an updated version here in the forums at some point. More importantly (and requiring a code change) is the parts factory issues incorrect scaled parts for .1 headers.


generic_logiclevelconverter_DIP_10_400mil_breadboard.fzp (31.6 KB)
Here’s the svg.

Font family looks correct, the svg scale is wrong (common, and won’t cause problems), the dimensions are set in px which will, change the document height and width from px to in (preferred) or mm. If the dimensions are px Fritzing will guess at the scale and often gets it wrong which causes scaling issues. I guess I should have asked what the problem you are see is and to upload the entire fzpz file for the part and I can run it through the part check script and fix it up.


A late thought, if your problem is the font size is too small, that is because you need to remove the px from the font-size. Css requires it (and thus most editors do it) but Fritzing doesn’t like it and sets the font size to zero. I rarely think of it any more because the parts check script removes them automatically.


I haven’t used it in a year, but there is a std ORCA in Win which is not the right one. It’s the one in the templates.

Took a while to get back to the topic.

Thanks for all answers so far, and here are the comments.

  1. If font family is OK, then still remains unexplained, why Fritzing won’t detect it properly and substitutes it with the Droid fonts. How to solve it?

  2. I have used on the Fritzing website provided svg templates (which apparently are outdated) as a reference. The distance between pins in those templates is 7.2 points, which results in the 72 points per inch resolution. If that is not correct (I assume, that is meant under “svg scale is wrong”), then what is “good svg scale”?

I have also tried to edit the svg content manually by removing px to no avail - the font still gets replaced after the import into Fritzing.

I guess, it would be the best to get a correct svg example, which can be imported into Fritzing without any glitches. Then its content could be analysed and compared to those svgs, which result into some issues, and eventually the critical mistakes could be revealed. Could anyone spare an svg with OCRA, which gets flawlessly imported into Fritzing?

Got it. Fritzing won’t recognise the “style” attribute. Instead, all attributes must be provided separately - not within “style” - then the import works properly. No need in providing example svg files.

Correct, I’m working on arranging that as part of the restart development effort, but it will probably be a while til its done as we are only just starting.

You were using OCRA and it was substituting Droid Sans? I think it should accept either valid font in most views (the graphic standards may call for only one font or the other in some views).

Correct, they are currently wrong, another thing on the long list of things to fix. Worse, parts factory generates incorrect (according to the graphics standards) parts as well, also on the list.
Some of the parts in core parts are wrong in various ways and should be updated too.

That was probably correct back when Illustrator user 72dpi as a resolution (when the svg standard was 90dpi and is now 96dpi). The scale is the viewbox to drawing cooridinate ratio desired to be 1/1000 as specified in the parts file format document here:

In practice a wrong scale isn’t user visible, the part will work just fine. It does however impact automated checking of parts which is why it is undesirable. In Inkscape setting the document properties Scale box to 10.41667 creates the desired 1/1000 ratio (the odd number being because of the 96DPI that Inkscape uses internally). With some pain, you can rescale existing documents, there are instructions in some of the posts in here.

Didn’t know that affected fonts as well, it mostly breaks parts with bendable legs and possibly gerber production. All these problems get fixed if you run the part through the part checking script available at

although it requires you to be familiar with the underlying xml. It also checks for and complains about many of the common errors people have made while making parts. I’m working on an update that will take an fzpz file and automatically unzip it but it isn’t done yet (and may be a while if we can get development going again).