[FIXED] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missing

Discussions about the development of the TechDraw workbench
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
aapo
Posts: 626
Joined: Mon Oct 29, 2018 6:41 pm

[FIXED] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missing

Post by aapo »

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.

20210124_TechDraw_dimension_degree_pic01.png
20210124_TechDraw_dimension_degree_pic01.png (44.27 KiB) Viewed 899 times
20210124_TechDraw_dimension_degree_pic02.png
20210124_TechDraw_dimension_degree_pic02.png (54.91 KiB) Viewed 899 times
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.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi

Post by uwestoehr »

aapo wrote: Sun Jan 24, 2021 4:57 pm I noticed two bugs in TD, namely the new equilateral tolerances are missing a degree sign for angles.
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.

Also, arbitrary under/overtolerances have somehow lost the possibility to set separate 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

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.
Fine with me.
aapo
Posts: 626
Joined: Mon Oct 29, 2018 6:41 pm

Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi

Post by aapo »

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.
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.

plusminus-degree.jpg
plusminus-degree.jpg (5.57 KiB) Viewed 823 times

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
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?
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi

Post by uwestoehr »

aapo wrote: Mon Jan 25, 2021 7:10 am You are right in that there must only be one unit, but degree sign is technically not a unit.
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.
Otherwise this would be ok, but this would not allow for different arbitrary text for both undertolerance and overtolerance.
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.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi

Post by uwestoehr »

uwestoehr wrote: Mon Jan 25, 2021 10:33 am Where is this defined?
OK, I found it:
AcroRd32_iAKFHiNKd1.png
AcroRd32_iAKFHiNKd1.png (25.99 KiB) Viewed 799 times

So I was wrong all the years :oops: and your fix to this is correct.
aapo
Posts: 626
Joined: Mon Oct 29, 2018 6:41 pm

Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi

Post by aapo »

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.
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.

Angular+tolerances.jpg
Angular+tolerances.jpg (80.83 KiB) Viewed 784 times
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.
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.
aapo
Posts: 626
Joined: Mon Oct 29, 2018 6:41 pm

Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi

Post by aapo »

uwestoehr wrote: Mon Jan 25, 2021 10:37 am So I was wrong all the years :oops: and your fix to this is correct.
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.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi

Post by uwestoehr »

aapo wrote: Mon Jan 25, 2021 10:59 am Please check any drafting manual,
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.

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.
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.
aapo
Posts: 626
Joined: Mon Oct 29, 2018 6:41 pm

Re: [Bug] The new equilateral tolerances are missing a degree sign for angles, also arbitrary under/overtolerances missi

Post by aapo »

uwestoehr wrote: Mon Jan 25, 2021 11:11 am 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.
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. :D

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.
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:
  • 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
That way, the format specifiers normally always stay the same, but it's still possible for a seasoned user to change the arbitrary format specifiers individually for interference fits and other alphanumeric cases.
Post Reply