Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dotted lines not showing, and thin lines become barely visible - AutoCAD print to pdf #4787

Open
Rullarfram opened this issue Jan 29, 2025 · 3 comments

Comments

@Rullarfram
Copy link

Rullarfram commented Jan 29, 2025

Edit* Just downloaded the pre-release build which seem to have fixed the icons in dark mode as i saw was brought up under Issues. The below problem is still present however.

Don't mind the boxes with linetype scale. They don't make any difference. It's annotation made while reviewing a drawing. Any type of scale will result in the lines not showing if they are dotted. Also noticeable when comparing sumatra to the other two pdf-readers is that any non-dotted lines are less clear in sumatraPDF, but they are still showing.

These are pdf's printed with AutoCAD using the settings in below picture:

Image

What it looks like in sumatraPDF.

Image

It's possible to see the lines if i zoom out to the point where the pdf covers about 5% of the screen, any closer and they dissapear.

What it looks like in Adobe:

Image

What it looks like in Bluebeam:

Image

I've tried different types of pdf printers in AutoCAD. I've opened the file with bluebeam, added annotations and such, saved it again in bluebeam. Problem still persists.

Either way. Except for this issue. I am extremely satisfied with sumatraPDF. It's my default PDF-viewer on both my workstation and private desktop.

@GitHubRulesOK
Copy link
Collaborator

GitHubRulesOK commented Jan 29, 2025

SumatraPDF uses MuPDF which has NO thicken lines thus the line thickness as per the content is generally applied at scale.

In CAD terms this is usually switch OFF adobes Line enhancer and work with PDF scalar units, this is compounded by CADD has a concept of ISO standard line pen weights

Where an ISO A4 drawing line thickness should not be less than 0.13 mm (roughly .005") and bigger drawings must PLOT OBJECT LINEWEIGHTS and A2 must use double thickness line weights eg the thinnest for A2 must be .01" = roughly 1 printers point

The problem with that concept is the thinnest is generally LESS THAN ONE Nominal Screen Pixel thus no need to show unless twice as big or upscaled by zoom in!

Done such comparisons before so at 25% zoom both SumatraPDF and Acrobat will show a 1/2 point line (1/144") the same as a red pixel line

Image

Here is the file you can edit whilst viewing so even at 00.00 (dont change the number of characters whilst saving or the file will be corrupted

minimal line.pdf

Image

Image

@Rullarfram
Copy link
Author

Interesting, and thank you for clarifying the specifics and technical reason as to why. You've thought me something new today.

So, at 00.00, a full line will be visible, but barely and as soon as that full line becomes dotted, it loses the last property that would make it visible (something along those lines).

If i understand you correctly, the number 00.00 is the same as you'd set a certain line weight in CAD, and ticking the "Plot object lineweights" box.

I opened up a random pdf with notepad++, just as i did the one you linked.

Mostly its mumbojumbo, but some key properties match your file. Just out of curiosity, do you know if the contents of a pdf have a specific language that notepad++ can download as a plugin?

@GitHubRulesOK
Copy link
Collaborator

GitHubRulesOK commented Jan 29, 2025

@Rullarfram
PDFs started simply as Data Xchange for Printing (think DXF as Plain Text) the language is Latin1(American) see color not colour.

The Apple (Then Adobe) laser developers were using a Full blown Programming Language called PostScript so simply neutered that to be a bit dumber by post distilling processes, then adapted it by juggling to show beams on Cathode Tubes (Today we use LCD)

Today we embed the images as binary rather than RGB text values and use compression to add more mumbo jumbo like pretend they are secure. Just decompress to a faster work copy like the one I wrote by hand (I do use a hexaDECIMAL editor to check it has correct decimal math values)

Here 3 parts are needed for an image
5 is the transparent black lower left corner layer with a value of 7 !
6 is the xy placement @ 1:1 scale and default unchanged where 72=1"
and position 7 is the colours where Red is ff0000 and as per above bottom line is black white black 000000ffffff000000

Image

5 0 obj <</Length 9/Type/XObject/Subtype/Image/Width 3/Height 3/BitsPerComponent 1/ColorSpace/DeviceGray/Filter/ASCIIHexDecode>>
stream
ffff7fff>
endstream
endobj
6 0 obj <</Length 46>>
stream
1 0 0 -1 -0 72 cm 72 0 0 -72 0 72 cm /Img3 Do
endstream
endobj
7 0 obj <</Length 55/Type/XObject/Subtype/Image/Width 3/Height 3/BitsPerComponent 8/SMask 5 0 R/ColorSpace/DeviceRGB/Filter/ASCIIHexDecode>>
stream
ff000000ff000000ff00ffffff00ffffff00000000ffffff000000>
endstream
endobj

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants