View Issue Details

IDProjectCategoryView StatusLast Update
0002034Part[FreeCAD] Bugpublic2018-01-05 21:11
ReportertoehserAssigned To 
Status confirmedResolutionopen 
PlatformUbuntu 14.04.2 x64OSLinuxOS Version3.13.0-49-generi
Product Version[FreeCAD] 0.17 
Target Version[FreeCAD] 0.18Fixed in Version 
Summary0002034: Measurement arrowheads are ridiculously out of proportion at some scales/zooms/measurements.
DescriptionSee (attached to ticket)
Steps To Reproducemeasure something small
Additional Informationarrowheads even overlap into hourglasses
Tags#lowhangingfruit, #pending


related to 0002520 closedyorik Drawing Dimension Arrows incorrectly scaled or placed in Export PDF (fixed in Qt5) 



2017-01-24 00:28

manager   ~0007941

Last edited: 2017-01-30 20:03

View 2 revisions

Please retest on 0.16
Forum thread:

Edit: Another thread found at


2017-01-24 04:15

manager   ~0007943

I confirm this bug in current master.

Steps to reproduce:

1. Create a Part Cube of dimensions 0.1 x 0.1 x 0.1 mm
2. Select two vertices
3. Click on "Measure Linear" from the Measure toolbar in the Part workbench
4. The measurement arrows are disproportionally huge.

OS: Ubuntu 14.04.5 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9747 (Git)
Build type: None
Branch: master
Hash: f5c0f579cbd7ce668727f8835946e4e9abc0eec6
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17


2017-01-30 13:39

manager   ~0008102

Changing status to 'confirmed'


2017-03-10 00:16

manager   ~0008601

Last edited: 2017-03-10 00:18

View 2 revisions

Copypasta from
tanderson69 wrote

    Been several iterations so can be hard to find. The part measure entities are not document objects and live as pure coin3d objects. This means they have no view provider. The arrow head creation is at:

    setting up 'autoscale' in coin3d seems harder than it should be, at least to me. Anyway I did make it work for the default reposition dragger. You can use it by double clicking on a primitive. You can find the code here.

    luke parry added a custom node, but I have never used it to know if it does what you want.

analog999 wrote

Thanks for the pointers. I don't have the build platform set up, hell I don't even know what you guys recommend, gcc or something I'm assuming. Anyway, just looking at TaskDimension.cpp, the cone size of the arrow, which is the problem, not the arrow itself, is set with these lines:


(similar for the cones at line 1060)

I don't know the correct method for calling the function, but couldn't you could calculate the scale factor off the vector at around line 432:

textVecCalc->dot(A,B) // should return length of the 3D arrow

And again, at around line 1137.

Then you know based on the size of the vectors that make the arrow length, say are fine at 20mm (just guessing), you could then scale the cone size based on that dot product in relation to 20mm.

Of course, maybe I'm missing something here? I am not familiar with the code, or with Coin3D, just a brief look at both, but it looks like an easy fix to me.

The reason this is OK is that if you are looking at a small area, the cones NEED to be small. Even if you were zooming out and looking at the part in a wider view, it doesn't help to have the cones be big and overlapping. Basically, I'm saying scale the cone based on the arrow length, NOT the camera view.

The other option is how about just not displaying the arrow cones at all? It could be a checkbox in the preferences. I don't see why they're really necessary anyway. With that, you just make it a conditional based on the global preference around lines:


Anyone who has the build environment already set up care to test or implement either of these suggested changes?

I realize that this may not be as important as implementing a much cooler feature, but as a novice user (at this point I might call myself novice->intermediate as there are many features I stil am not familiar with), the arrow cone issue is one of the first things that I ran into that has bugged me from probably the first or second part I made, and continues to bug me pretty much anytime I am working on something with tight tolerances. If it's that easy and annoying of a "bug" for someone to find, and at least just having the option to turn them off is available, that might keep someone from getting really frustrated and saying "f-this, I'll just go back to whatever-cad"

I think FreeCAD is awesome, by the way. Thank you guys so much for creating / working on it. I will be happy to make the change myself, but getting the build environment all set up is going to take some time that I don't have at the moment. I don't know if this really matters to anyone who is doing the regular builds / code merges or what have you.


2017-05-01 23:00

manager   ~0008841

Re-added attached photo

IMG_0010.PNG (31,319 bytes)
IMG_0010.PNG (31,319 bytes)

Issue History

Date Modified Username Field Change
2015-03-31 12:57 toehser New Issue
2017-01-24 00:21 Kunda1 File Added: fc2.png
2017-01-24 00:21 Kunda1 Description Updated View Revisions
2017-01-24 00:28 Kunda1 Note Added: 0007941
2017-01-24 00:28 Kunda1 Status new => feedback
2017-01-24 00:29 Kunda1 Tag Attached: #pending
2017-01-24 04:15 normandc Note Added: 0007943
2017-01-30 13:39 Kunda1 Note Added: 0008102
2017-01-30 13:39 Kunda1 Status feedback => confirmed
2017-01-30 20:03 Kunda1 Note Edited: 0007941 View Revisions
2017-02-01 23:56 Kunda1 Tag Attached: #lowhangingfruit
2017-03-10 00:16 Kunda1 Note Added: 0008601
2017-03-10 00:18 Kunda1 Note Edited: 0008601 View Revisions
2017-03-10 00:21 Kunda1 Product Version => 0.17
2017-03-10 00:21 Kunda1 Target Version => 0.17
2017-05-01 22:59 Kunda1 File Deleted: fc2.png
2017-05-01 23:00 Kunda1 File Added: IMG_0010.PNG
2017-05-01 23:00 Kunda1 Note Added: 0008841
2017-06-27 11:31 Kunda1 Relationship added related to 0002520
2017-10-18 14:21 wmayer Project FreeCAD => Part
2018-01-05 21:11 wmayer Target Version 0.17 => 0.18