A line which does not exist on my layout is printing across my entire layout so consistently I have had to release the drawing for construction with the line present and identified as a software error. There are no hidden objects on the layout, and no such line on any of the few hidden layers in the project. Thoughts welcome.
Screenshot with the white background is the print preview showing the line. Grey background image is print display view of the layout in rhino.
I assume you are describing the horizontal line in the middle of the image?
Does your file have any bad objects in it?
Command: SelBadObjects
If that’s not it, we’ll need the file to figure it out.
Thanks John
No Bad Objects. Just loaded to the file to tech email address to your attention. Problem is consistent across pdf writers Rhinpdf, Cutepdf, AdobePdf.
The file has arrived.
What are the specifics to repeat this problem?
Which layout are you using?
I need ALL the details to repeat the problem.
The file you sent is missing all of the image files you used, and a font I don’t have, but I doubt those have anything to do with this issue.
Thanks
I don’t have that font either. Yes there are no textures included.
open layout 05aFence and look at the area at the bottom which matches my uploaded images above.
ctr-p>Rhinopdf
look at the same area on the print preview. Do you get a line?
I found it.
It’s a buggered up Text object.
I’ve deleted everything else out of the file.
Go to the Layout and type SelAll to select it.
Thankyou John. I found that object earlier today and deleted it. Lo and behold there it is again.
It shows as a dimension on properties on my project. Let’s talk a bit about this sort of corrupted dimension. There’s another one way off to the top of this layout. These probably were placed somewhere on the sheet but have sproinged of into the hinterlands. I must inspect the drawing and replace whichever dimensions have disappeared. (This is the first time I’ve found such an object which won’t display unless sufficiently zoomed out. That’s new. ) My Rhino colleagues find that dimensions sproing off into space every so often on their layouts also, but we don’t know what causes it.
Any thoughts on how to avoid this. It used to have to do with dimensioning blocks - such that I stopped snapping to any part of a block. It’s happened less often in the past year and I’m dimensioning to all types of objects, but here it is again.
Sorry, I don’t. That’s well beyond my limited Rhino skills.
Hopefully an expert will jump in with an idea.
I’ve saved the file and created a defect report.
Maybe one og the bigger brains can figure out a way to handle this more elegantly.
Hi @djhg,
Looks like the dimension’s control points are stacked. Check out the video on the issue below:
https://mcneel.myjetbrains.com/youtrack/issue/RH-65488
– Dale
@dale
Is there some way to detect Annotations with stacked Edit Points?
My guess is this was imported into the file and not buggered up by this user.
I can’t seem to gain access to the JetBrains to see the video. Does this refer to the dimension grip and arrow grip being at the same point?
That could be, but I have definitely had the issue with dimensions I’ve created myself.
You should be able to see the video, at the linked I provided, now…
Thanks.
I’d nominate this as a bug. This type of object can so readily be created, I think. A dimension can easily and inadvertently be snapped to the same start and end points when the snap or planar/project settings aren’t as expected (grid snap, for example). If the resulting anomaly disappears only to become visible only occasionally, recognizing (and rectifying) the issue can be hit or miss.
(It’s also worth mentioning that my colleages and I have had the experience of dimensions which do not have coincident start and end points sproinging away from time to time.)
To catch this bug, we will need the DWG, DXF, etc. file that you imported that brought this in.
If the buggered dimension was created in Rhino through point editing, or imported from another 3dm file, there isn’t much we can do.
The general Rhino ethos is to give you free reign with the tools and count on you to not do crazy things; like stacking control/edit points.
Any chance you can track down the origin of this problem?
Basically, We do not let you create a dimension like this in Rhino initially. We can not stop anyone from inappropriately dragging points around after the fact.
When we translate an imported, non-native file, we are creating those dimensions. I’m concerned there is a bug in that code. That’s the reason for the request for an example.
It was created in Rhino, I’m pretty sure - perhaps imported from it.
Bummer.
A car maker can build a car that can be operated safely.
They can not design one that can’t be driven into a ditch.
Seatbelts.
I think this might be where there’s a bug. I believe this dimension was on the perspective with an override on the text and the value manuallly entered. Maybe Rhino has a problem with that and creates the cursed dimension?
That’s almost Tao
Dimensions are always created coplanar to the current viewport CPlane.
If you can come up with a picking cycle that creates these things, I’d like to hear it.
That said, as an old drafter, I believe a dimension should never be shown in a Perspective view where it can not be checked on a print, unless it’s pencilled in for an in-house shop drawing. Certainly never on a drawing I sent out.
