May I ask how you are creating the dotted lines? that seems to be the problem, a space and a period, you are manually counting and spacing and the plot drivers seem to drop them off (same exact ones too). You might benefit from using an actual TABLE object instead of MTEXT with manual spacing of dots to identify lines. As far as I can tell, AutoCAD is dropping the points since it does this in DWF and plotting to paper too.
Yes we are using a space and a period to create the dotted line. What do you mean "seems to be dropped off"?
Also, what do mean by "same exact ones"? On the 4th line of grey dots, the dot to be dropped is the 184th character in the line. On the last line (#6) the dot to be dropped is the 167 character.
The table may work, but would not allow the dotted lines to be created from the end of each line of text, the line could only be created in the next cell, which would make it appear to be started from some random point in space.
I could have separate text objects for: the Text, the Grey dots & the check boxes, but this would make the text block very cumbersome and annoying to edit.
Do you have any suggestions on how to fix problem but keep the same intended output?
To Both - I'm just butting in:
"May I ask how you are creating the dotted lines? That seems to be the problem,..."
No, that's just what he's using to visually show you the problem... The problem is how AutoCAD is CHANGING the width of .TTF text used in it's drawings - It is different than it shows in AutoCAD. (.SHX fonts did not have this problem) Those vertical lines he drew in AutoCAD are place holders to show where the AutoCAD shows where the text should be, and you can see how it doesn't line up anymore once printed or PDF'd. - That is the problem and the point to this whole thread.
"On the 4th line of grey dots, the dot to be dropped is the 184th character in the line."
Unless I miss counted, I count the same number of dots in both the cad file of that line as the PDF print out (74 periods). So I am guessing, that AutoCAD realized the change in width, and added a 'tab' or extra spacing to compensate, so the end dot would land closer were it should have been... and that's why it appears to be 'missing' a dot....????
- I for a 'work around' on your 'dot issue', I would suggest making a linetype that has a small dash then long gap - draw in a polyline, and give it a width. The end result is a line that can mimic the appearance of the dots... this will keep the dots consistently spaced and easier to work with than counting out text dots.
Just a suggested workaround, as I don't think the real problem is ever going to be fixed....
Whether I plot to PDF, DWF, laser printer or inkjet plotter, the same exact dots get dropped. No mystery, AutoCAD does not like your method of identifying a line with a row of spaces and dots . . . . . . . . . . . . . . . . . . . . . . . .
Table lines can be hidden or dotted, your check boxes can also be table cells.
Or simply underline each line with a check box at the end
Or as the other post suggests, floating a line with a linetype in between the text and the boxes (seems to add another element to manage though).
Or simply forget about TTF fonts and use SHX stick fonts as also suggested. AutoCAD draws these as line objects, not fonts, when plotting.
Simply put, AutoCAD seems to mishandle your current method so I suspect there is no fix and it's worth exploring other options. Try the Table idea, it does more than just draw a grid around text. And it's all one object.