Attributes semi-randomly display text upside-down in PDF plot

[solphi.guthrie]

Hello all,

Really perplexed here. I have a file where I am using multiple instances of the same block with attributes, but when I print some of these attributes are displayed upside down.

I have tried a print directly from modelspace, I have tried printing the layout from a sheet that uses the problematic drawing as an x-ref, print preview in both circumstances shows the text in the correct orientation but when I generate the PDF the actual text occasionally is inverted.

I have checked the orientation of the blocks as well as any text settings both within the block editor and within the attribute definition dialog boxes. I have tried printing the file in AutoCAD 2021 as well as 2023. There is nothing that seems to be problematic, and while the inverted text appears somewhat random, the locations of the inverted text are consistent from plot to plot (ie, the same instances of the blocks are affected each time, even though there does not seem to be any differentiation between the affected blocks and the blocks around them).

Please note:
- this is happening on more than one block type in the same file, seemingly randomly. note that the inversion is happening on rows G-30, G-27, G-24, and G-23 with my 10-string blocks (all the blocks in rows G-22 to G-32 are identical), and also on row G-21 (rows G-12 through G-21 are my 6-string blocks).
- all settings for the blocks are identical, there is no perceivable difference between the affected blocks and non-affected blocks

- I have audited the files, and also purged the files to ensure any errors that might be causing the problem are corrected. Both Audit and Purge are showing no errors and no more elements to purge.

I am attaching a couple of image files as reference (these are from modelspace and print preview where the text is not inverted) as well as PDFs showing the print error from a modelspace plot (from the source file) and a paperspace x-ref'd plot (the actual planset plot minus the titleblock). If there is an easy fix without uploading the specific CAD that would be preferred as I need to redact or remove some information were I to upload the CAD file, but I can do this if need be. Anyone seen anything like this before? Any suggestions?

Any help that can be offered is much appreciated!

Thanks so much for your help in advance!

[solphi.guthrie]

I have gone ahead and redacted the base file so as to expedite any help. Please see the attached file, and thanks!

Again, the problem only manifests when plotted (does not show up in the software view or plot preview). See my above post for specific areas to look for in the plot files.

[dmfrazier]

"...when I print some of these attributes are displayed upside down."

@solphi.guthrie, I'm sorry, but I cannot see any "upside down" attributes in the images you posted.

Can you post another PDF, just a small portion, with the attributes highlighted or circled?

[dmfrazier]

Nevermind...

I ran a plot and am able to see what you describe:

Still poking around...

[pendean]

@solphi.guthrie wondering why you did not try to highlight any of these in your screenshots for better observability for those of us not familiar with your content.... BUT... no text in the PDFs or screenshots you provided are upside-down from what I can tell either: could it be you do NOT have (or have different) fonts being saved in those PDFs?

Or are these the incorrect ones to share here?

[dmfrazier]

The attributes are not upside down, actually, they are mirrored.

I thought it might have something to do with the UCS rotation, but changing it seems to make no difference.

Which PDF output driver(s) have you used?

[solphi.guthrie]

All,

Please forgive me for not highlighting the problem attribute, it's my first time posting in the forum (after over a decade of almost daily CAD work) and I should have thought of that. My bad!

Digging down further into the problem on my end, Adobe PDF and Microsoft Print to PDF generate the attribute text with proper orientation, but these printers are clunky and take forever to print (and failed miserably printing the problematic file when linked as an x-ref)

the problem seems to reside with either the built in AutoCAD PDF printers (DWG to PDF or AUTOCAD PDF), or their interfacing with the attributes in these specific blocks.

See attached a new screenshot of the problem in a PDF file (inverted entries are highlighted), as well as the actual PDF with some inverted entries highlighted.

If I have left out anything that could be helpful, please ask and I am happy to provide it as quickly as possible! I much appreciate the assistance!

[solphi.guthrie]

 reposting the image snippet embedded in the forum post for clarity!

[solphi.guthrie]

@pendean ,

See the above post for an example of the inverted text. The font is Arial, and I've generated hundreds of sheets with this font over the last few years, but I've not had to embed an attribute in a block like this since about 2019.

The problem only manifests itself with the attribute text (inside the block) and the problem is not consistent from block to block (blocks are identical).

Once again, I appreciate any help or consideration and please excuse me for not better detailing the problem with my first post.

[solphi.guthrie]

@dmfraziergreat observation and perhaps an important point, they are mirrored and not upside down.

the internal autocad PDF drivers (DWG to PDF, AUTOCAD PDF) seem to be problematic, or at least how they are interfacing with the attribute text in the block.

If I print with Adobe PDF or Microsoft Print to PDF the bug doesn't manifest, but those drivers are garbage and a) take forever and b) fail when I try to print a file with the problematic base file x-ref'd.

[dmfrazier]

I don't know if this will help or not, but after using BEdit to change the attribute's style to "Standard" (which uses simplex.shx), running AttSync, and then plotting (one time) to PDF using AutoCAD PDF (High Quality Print).pc3, the mirroring did not occur.

(Was it the style change, or was it the AttSync? Hmmm.)

[dmfrazier · Accepted solution]

Changing this PDF Options setting for the aforementioned PC3 also resulted in a plot without mirrored attributes:

[solphi.guthrie]

@dmfrazierThat looks like it does the trick! Are you aware of any repercussions for changing these plot settings? I was able to copy and paste the text in question out of the file, so I suppose it's still searchable and all.

I just spent the last hour and a half with AutoCAD tech support and they've flown this up the flagpole to the development team. I will keep everyone posted, I'm tempted to just accept the above solution but let's see if there's not a more robust explanation before I close this thread (for all of our sake).

No need for further responses otherwise at the moment, I don't think. Thank you all for considering my conundrum.

[dmfrazier]

"Are you aware of any repercussions for changing these plot settings? I was able to copy and paste the text in question out of the file, so I suppose it's still searchable and all."

Well, it was my understanding that converting text to geometry would mean that text in the DWG would not be "text" in the PDF (surely, it would be "geometry", right?), so it would not be "searchable and all". But you seem to be reporting otherwise. (I can report a similar experience with the PDF I produced from your DWG, but I cannot explain it.) Perhaps it depends on the tool used to do the searching (and all). I use Foxit Reader.

(I learn lots of new things every day.)

It also seems to increase the PDF file size (perhaps significantly when there's lots of text).

Edit:

Apparently the convert text to geometry setting does not apply to TrueType fonts; perhaps it affects only text objects using AutoCAD SHX fonts. The PDF properties indicate that the following fonts are referenced in the PDF:

[TomBeauford]

I've seen this issue before, the block "1P60@60DEG F TR ID2 PVBlock" along with it's attribute are drawn vertically while inserted in the drawing horizontally making makes displaying them properly confusing. If the block was created at a different angle it wouldn't have been an issue.