Erroneous Data in the gtol.sym file

Discussion created by Jim Sculley on Aug 18, 2017
Latest reply on Aug 30, 2017 by Jim Sculley

Like • Show 1 Like1
Comment • 8

I've noticed some entries in the gtol.sym file that look like they have errors:

Line numbers are on the left. Notice the extra decimal point at the end of each line. It's the same in SW 2016 and SW 2017.

They do not seem to negatively impact anything from what I can tell. I see things like this and wonder how the software deals with such obvious screw ups. Somewhere in the code there is a workaround to deal with these 10 errors in a file with 7404 lines.

As a result of this screw up, I now have to put a workaround in my code so that when I try to turn '1.52.' into a number and it pukes, I can catch the error and remove the extraneous decimal point and try again.

Outcomes

8 Replies

Matthew Lorono Aug 21, 2017 10:37 AM
Jim,

Thank you for pointing this out. Please see if you can have these filed as a low priority bug with your VAR. In the meantime, it is doubtful that we have special code to handing these specific cases, as the method to parse this file likely never even reads this extra period. If the extra period appeared in the middle of l line, it would cause issues. With the extra period at the end, it seems to be just outright ignored.
Like • Show 2 Likes2
Actions
- Jim Sculley @ Matthew Lorono on Aug 23, 2017 9:49 AM
  Thanks Matthew. Can you provide some clarification on this bit in the file header:
  
  ========================================
  ;; Units:
  ;;
  ;; All x, y, and radius values are in the symbols grid space (0.0 to 1.0),
  ;; where 0,0 is the lower left corner and 1,1 is the upper right corner.
  ;; The grid space is considered to be the height of a character squared.
  ;; All angle values are in degrees.
  =========================================
  
  If the grid space is from 0.0,0.0 to 1.0,1.0, why do many of the symbol coordinates include negative values and values greater than 1?
  
  Experimentation has shown that there is no practical limit to the coordinates. X-Y values can be as high as +/-20km and will still be drawn.
  Also, if the grid space is considered to be the height (pixels, inches, ???) of a character squared, why does a line from 0.0,0.0 to 1.0,1.0 next to the letter A look like this:
  The line is clearly not the height of the character squared in either the x or y direction. In fact, 0,0 seems to lie between the character baseline and descender height:
  
  This lack of clarity makes it very difficult to create custom symbols without multiple iterations of trial and error.
  Like • Show 2 Likes2
  Actions
  - Matthew Lorono @ Jim Sculley on Aug 23, 2017 1:12 PM
    The description in the file is simplified. Editing of symbols is more complex, as it requires one to think of terms of how Cartesian Coordinates relate to the font size established by Windows. The 0,0 to 1,1 square is what Windows considers as the space for a character. It's elastic to always match your set font size. It's not an absolute size on the sheet. If you change your font size from 10pt to 15pt, the 0,0 to 1,1 area grows in kind.
    
    Values larger than 1 simply extend beyond the normal area assigned to characters. Same thing for negative values in down and left directions.
    
    I've personally created almost all of the new symbols you've seen added to the GTOL.SYM file since SOLIDWORKS 2012. So, I'm well aware of the current limitations and difficulties. I would like to address some of the more challenging points of symbol design in SOLIDWORKS at some time.
    Like • Show 0 Likes0
    Actions
    - Jim Sculley @ Matthew Lorono on Aug 25, 2017 2:34 PM
      Matthew Lorono wrote:
      
      The description in the file is simplified.
      And wrong in places. For example, the comment about text states:
      
      A,TEXT xLowerLeft,yLowerLeft,<letter(s)>
      
      So, if I create a symbol that generates a grid, from 0,0 to 1,1 in 0.1 increments like this:
      
      and then I add a single text character at location 0,0 which is the lower left of the text per the comments in the file, I would expect to have the character more or less inside the grid. Instead, I get this:
      So, the xLowerLeft,yLowerLeft coordinates above are actually the center of the text. Adding more characters bears this out:
      If I use 0.5,0.5 for the coordinates, it looks correct:
      
      The text also renders with a slight vertical offset from where it would be in a regular annotation:
      
      Possibly rounding errors, possibly coding error.
      Like • Show 2 Likes2
      Actions
      - Matthew Lorono @ Jim Sculley on Aug 30, 2017 10:07 AM
        Thank you for pointing out the issue with the instructions.
        
        For the vertical offset, this is actually a carryover from how Windows defines the area for characters to support descenders such as lowercase p and j.
        Like • Show 0 Likes0
        Actions
        Jim Sculley @ Matthew Lorono on Aug 30, 2017 2:49 PM
        If the offset was to allow for descenders, wouldn't it be more severe? Notice in the image below that both letters in the symbol on the right are offset vertically above the corresponding letters in the normal annotation text.
        For what I'm working on, it would be very helpful to know the calculation by which a single character of text is located vertically within the symbol area.
        Like • Show 0 Likes0
        Actions
Jim Sculley Aug 30, 2017 9:54 AM
If you create a text symbol with more than 15 characters it crashes SOLIDWORKS.
Like • Show 1 Like1
Actions
- Matthew Lorono @ Jim Sculley on Aug 30, 2017 10:06 AM
  Have you had a chance to have this filed as a bug? It's one thing to not support 15 character long symbols, but it's another to actually crash.
  Like • Show 0 Likes0
  Actions

Erroneous Data in the gtol.sym file

Outcomes

Related Content

Recommended Content