Mirror command

For the mirror command, it does not matter what value I give MIRRTEXT ( 0 or 1 ) my text in the mirrored portion is always wrong. It is never rotated correctly as you would expect.
What am I missing? Thanks H. Hampton.

Comments

  • Is the problematic text within a block?

  • No it is the result of single line text command.

  • Roy Klein Gebbinck
    edited July 2017

    Changing the MIRRTEXT setting does not affect existing texts.

  • What font is being used?

  • Anthony Apostolaros
    edited July 2017


    Mirroring doesn't reverse the justification of a simple text when MIRRTEXT is off.

  • I have run into this. Once you mirror text so that it is backwards, and then later changer MIRRTEXT to disable mirroring, you have to change MIRRTEXT back to what it was to undo the problem.

    On my v14, mirroring text always will mirror the justification, regardless of the MIRRTEXT setting.

    -Joe

  • Mirroring a text will not mirror its justification. It only appears that way.

    IMO text should never appear mirrored (even if nested in a block). The text justification however should be mirrored. I do not understand why this has never been implemented in 'dwg-CAD'.

  • I got to use a program called Medusa a few years ago. It came about back when a main frame computer was accessed by several terminals, and pre-dated AutoCAD. It was interesting to see several features that AutoCAD inherited, but are never used today, such as blipmode (which puts a tiny cross-hair anywhere you click on screen).

    I would speculate that the mirroring of text came about because you need that feature for when text gets mirrored in production. E.g. etching on the back side of a transparent object or machining a mold.

    I suspect that the lack of desktop publishing tools at the time would have pushed AutoDesk to include some features common to a desktop publishing program. Though, I can't imagine why they took so many years to allow multi-line text, or a graphics interface for choosing a file to open. Perhaps it was simply a marketing decision for planned obsolescence.

    -Joe

  • Anthony Apostolaros
    edited July 2017

    In the example I posted, all the texts and mtexts except one have Left or Top Left justification according to the Properties bar, even if they appear to be right-justified. The one exception is the mtext that was mirrored with MIRRTEXT = OFF. That one has Top Right justification according to the Properties bar, and it looks and acts like it's right-justified. So mirroring did reverse its justification, as one would expect. I mirror mtext/leader combinations all day long.

    The ones that appear to be right-justified after being mirrored also behave as if they were right-justified when you edit the text. I don't understand why some of them are identified in the Properties bar as being left-justified, but I don't care because those all have backward text, which I never use.

    The real anomaly to me is the single-line text that was mirrored with MIRRORTEXT = OFF. That one doesn't even look or behave as if it were right-justified. I think it should.

  • Everyone thanks for the info. Very helpful.

  • I don't think this is related, but I just got a drawing from a company in South America. The text is left-justified, but the text is centered on the left edge when I open it in my v14.

    I don't know the history of this drawing, though it has clearly been at least somewhat cleaned up from the original file. The drawing was set to inches, units, but it was obviously drawn with meters as the unit.

    Apparently there is more than one way to mess-up text justification.

    -Joe

  • The MIRRTEXT system variable controls whether text entities are mirrored by the MIRROR command. A mirrored Text entity has its Backward property set to YES. You can simply change this property in the Properties window. To 'unmirror' an MText entity use the MIRROR command and answer Yes to the final prompt (Delete the original entities?).

  • The text display error has cost me at least 3 or 4 hours today. I have already started a support request, but since I am on v14, I don't know that it is of much value. I suspect our two issues are related. You didn't say what version you are on.

    Attached is both a DWG that demonstrates the problem, and some screen grabs showing it.

    Briefly, there is some Mtext that is justified as TC. But, it displays centered on the left side of the text box. If I change its formatting to left and then back to TC, it will display properly. But, if I save the file and then re-open it, the text formats as it was before I edited it. The text is also moved to the left.

    If I audit this drawing, there are many errors. If I fix them, it does not solve the problem. If I audit, save, close, and then re-open it, and audit it again, there are no errors. But, if I edit the problem text, and then re-audit, there are several errors reported.

    -Joe

  • Exploding the problem text will stop the problem. By the way, if I include the problems this created yesterday, it is probably closer to 7 hours that were wasted on this bug. I also put out a few drawings where some of the problem texts were fixed at one time, but I didn't detect that the problem kept un-fixing my fixes.

    Bugs are expensive for the user.

    -Joe

  • @Joe Dunfee:
    Strange that you have wasted so much time on that problem (which has nothing to do with mirroring). Wouldn't it have been faster to just create new mtexts? And why not consult this forum sooner?

    Your problem is caused by an mtext formatting code that is not supported in V14 (or V16). Try using StripMtext.

  • The initial hours lost were from not realizing the problem was there. I was concentrating on one part of the drawing, and then need to work on a different project for a while, and then back to the first one and on to a different part of the drawing. At some point, I noticed the problem with the 1st area, and I fixed everything... at least until I re-opened the drawing. "I thought I fixed that!". I must have forgotten to save the changes! Then I would fix the problem again. At one point, I was rushed to just get one of the drawings out, so just as long as that one printed OK, at least that particular drawing would be done. Note that the example drawing I uploaded only showed a small portion of the drawing, so the complexity of the drawing made it harder to see the exact trigger.

    Eventually I realized something was happening that was not my fault. But, what was causing it? Then, the investigation starts, consuming more time.

    This particular bug was tricky because you could apparently fix the problem, and then another day it would come back.

    Thanks for the StripMtext solution.

    -Joe

This discussion has been closed.