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.
Thanks Matthew. Can you provide some clarification on this bit in the file header:
;; 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.
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.
Matthew Lorono wrote:
The description in the file is simplified.
And wrong in places. For example, the comment about text states:
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.
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.
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.
If you create a text symbol with more than 15 characters it crashes SOLIDWORKS.
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.