Hi,
I noticed two bugs in TD, namely the new equilateral tolerances are missing a degree sign for angles. Also, arbitrary under/overtolerances have somehow lost the possibility to set separate arbitrary tolerances (e.g. "std project tolerance" for under, and "as tight as possible" for upper). I fixed both bugs, and there will be a PR soon. Also, Uwe, I think the dimension string handling is supposed to happen in DrawViewDimension.cpp, not QGIViewDimension.cpp, so I move&modified your new code there. All the other dimension string handling happens there, and the QGI is supposed to be reserved for the graphics stuff, just to keep everything tidy.
The first bug you can see below, the ° sign is supposed to be included in both of the numbers. I think this is supposed to happen only for angular ° character, but not for any other units.
[FIXED] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missing
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
[FIXED] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missing
- Attachments
-
- 20210124_TechDraw_dimension_degree.FCStd
- (21.71 KiB) Downloaded 20 times
Last edited by aapo on Sun Jan 31, 2021 5:00 pm, edited 1 time in total.
Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi
Pull request for fixing the bugs is here: https://github.com/FreeCAD/FreeCAD/pull/4310
Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi
I don't see a bug as it is. There must only be ne unit, so either
12.50 mm or 12.50 ± 0.50 mm
15 ° or 15 ± 1°
Why do you think it must be
12.50 mm ± 0.50 mm
This is only necessary when the units are different but the standard recommend to use the same unit if possible. So 12.50 cm ± 0.50 mm is possible but not recommended.
I did this purposely because both standards (ASME and ISO) do not allow to use different formatting for the overtolerance and the undertolerance.Also, arbitrary under/overtolerances have somehow lost the possibility to set separate arbitrary tolerances
With your PR you re-add them. Instead I would only allow to set one arbitrary tolerance. The reason is that e.g.
12.50 + I don't care - 0.50
is weird. So if you need an arbitrary tolerance statement, it should be done as equal tolerance like:
12.50 ± I don't care
Fine with me.I think the dimension string handling is supposed to happen in DrawViewDimension.cpp, not QGIViewDimension.cpp, so I move&modified your new code there. All the other dimension string handling happens there, and the QGI is supposed to be reserved for the graphics stuff, just to keep everything tidy.
Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi
You are right in that there must only be one unit, but degree sign is technically not a unit. If you look at any drafting manual, e.g. http://www.mehmetaladag.com/wp-content/ ... RANCES.pdf, you'll see that the degree sign should be repeated in ± tolerances (as it's not a unit). Also, if you'll try the PR version, it should handle other units (e.g. mm) the correct way, i.e. 12.50 ± 0.50 mm. The change should only concern angular units.uwestoehr wrote: ↑Mon Jan 25, 2021 12:36 am I don't see a bug as it is. There must only be ne unit, so either
12.50 mm or 12.50 ± 0.50 mm
15 ° or 15 ± 1°
Why do you think it must be
12.50 mm ± 0.50 mm
This is only necessary when the units are different but the standard recommend to use the same unit if possible. So 12.50 cm ± 0.50 mm is possible but not recommended.
Otherwise this would be ok, but this would not allow for different arbitrary text for both undertolerance and overtolerance. My original implementation supported that, but apparently you did change that without discussion on the forum. Maybe we could make it so that OverToleranceFormatSpec and UnderToleranceFormatSpec will be made automatically equal, unless the user has selected arbitrary tolerances?I did this purposely because both standards (ASME and ISO) do not allow to use different formatting for the overtolerance and the undertolerance.
With your PR you re-add them. Instead I would only allow to set one arbitrary tolerance. The reason is that e.g.
12.50 + I don't care - 0.50
is weird. So if you need an arbitrary tolerance statement, it should be done as equal tolerance like:
12.50 ± I don't care
Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi
Where is this defined? Up to now in all my work positions, at the university and industry, the degrees was treated as a normal unit. Only for typesetting the ° is an exception since there is no half-space between the number and the unit while this is the case or all other units.
In FC we have different unit systems and some use "deg" instead of °, then also the typographic exception does not occur.
But this is my point. We have 2 subissues here:Otherwise this would be ok, but this would not allow for different arbitrary text for both undertolerance and overtolerance.
1. the standards don't allow different formatting for over and undertolerance, so when you insist of having arbitrary tolerances for both, we nevertheless must assure that one one formatting is used.
2. having an arbitrary overtolerance but a real undertolerance is not explicitly permitted by the standards, but I googled around and cannot find a single example where this is done. Thus when you use arbitrary tolerances, you do it once. So why do you think we must provide that one can have independent arbitrary over- and undertolerance? A real-life example would help me to understand.
To clarify: I only removed the 2 independent formatting fields to follow the standards of having a uniform formatting for both.
Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi
Please check any drafting manual, or google for images of "angular tolerance", and you'll find plenty of drawings where the degree symbol is repeated. So far I haven't found a single image with equilateral angular tolerance with one degree symbol only after the tolerance value. It would help to convince me, if you'd show a sample from a drafting manual or a relevant standard supporting your viewpoint.uwestoehr wrote: ↑Mon Jan 25, 2021 10:33 am Where is this defined? Up to now in all my work positions, at the university and industry, the degrees was treated as a normal unit. Only for typesetting the ° is an exception since there is no half-space between the number and the unit while this is the case or all other units.
In FC we have different unit systems and some use "deg" instead of °, then also the typographic exception does not occur.
There is a need for 2 independent formatting fields, if alphanumeric interference fitting tolerances are used. See, e.g. http://catiadoc.free.fr/online/cfyugdr_ ... sa0405.htm. That is the reason for the 2 independent formatting fields in my original implementation.But this is my point. We have 2 subissues here:
1. the standards don't allow different formatting for over and undertolerance, so when you insist of having arbitrary tolerances for both, we nevertheless must assure that one one formatting is used.
2. having an arbitrary overtolerance but a real undertolerance is not explicitly permitted by the standards, but I googled around and cannot find a single example where this is done. Thus when you use arbitrary tolerances, you do it once. So why do you think we must provide that one can have independent arbitrary over- and undertolerance? A real-life example would help me to understand.
To clarify: I only removed the 2 independent formatting fields to follow the standards of having a uniform formatting for both.
Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi
Okay, no worries! Besides, you raised on important point: What if a unit schema puts up "degr" without the MultiUnitSchema as the angular unit? I'm not actually sure, if the "degr" should be repeated or not? It depends on whether "degr" is a unit or not; and this could go either way, one could say that as an angle unit it's similar to the "°", and therefore should be repeated, but on the other hand you could say that only "°" is explicitly defined to be repeated.
Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi
See my latest post.
Besides this, I think it is best to look at the standards because there are so many buggy manuals around. Standards/norm are exactly there to uniform all the different best-practices.
Many thanks, so there are applications for having independent arbitrary tolerances. Then I would only say, we need to assure that when both tolerances are real (not arbitrary), only one format specifier field as active and used.There is a need for 2 independent formatting fields, if alphanumeric interference fitting tolerances are used. See, e.g. http://catiadoc.free.fr/online/cfyugdr_ ... sa0405.htm. That is the reason for the 2 independent formatting fields in my original implementation.
Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi
That is true, but unfortunately I don't have an access to the standards. Good thing that apparently you have the relevant ISO standards at hand, so we can trust to find the correct implementation in the future cases, too.
Exactly, that is indeed where I think that your idea is better. Therefore, I propose that I'll amend my PR in the following way:Many thanks, so there are applications for having independent arbitrary tolerances. Then I would only say, we need to assure that when both tolerances are real (not arbitrary), only one format specifier field as active and used.
- If arbitrary==false: Changing either of the format specifiers copies the result to the other one
- If arbitrary==true: Changing either of the format specifiers leaves the other one as it is
- If using the new Dimension task tool: Changing the format specifiers copies the result to both of them