none
[MS-EMF] Rendering EMF Records problem.. RRS feed

  • Question

  • Dear,

     

    We are facing a problem or don’t have enough knowledge about a certain EMF Record.

    The situation:

    We render a document and text within the document where the text-alignment is set to right are rendered wrong (but it also happens when text-alignment is set to left). We have seen two problems when rendering the EMF Records.

    Or:

    -          the indentation space is random (= not all text is aligned to the same place on the aligned side).
    or

    -          the text is clipped and it doesn’t contain all the text (it’s cut off).
    The bounding box has the wrong size or the character spacing is wrong?

    The EMF Record that causes us problems is EMR_SMALLTEXTOUT AND happens when a bounding box is set.

    Did we forget something? Is there something that we need to know because this record is not fully documented? Is it an encoding problem (Unicode vs …) ?

    It would be great if we could render this EMF Record normal without text that has been cut off or without wrong indentations.

    What we do know if we render the document in Irfran View via a raster format that the text is rendered normal.
    (A temporary fix would be to convert the record to a raster format but: Is there a way to convert EMR_SMALLTEXTOUT to EMR_EXTTEXTOUT so that this can be rendered via a raster instead of using vectors?)


     

    Here are a fewrecords that cause us problems:

    [082] EMR_EXTCREATEFONTINDIRECTW       (s=368) {ihFont(5) ELF[name() style() vendor(0x00000006)] LOG[face(Arial), style(), charset(0),family(0),precision(0), height(-33), width(0)]}
    [037] EMR_SELECTOBJECT                     (s=12) {Table object: 5=OBJ_FONT}
    [030] EMR_INTERSECTCLIPRECT               (s=24) {rclClip(2113,181,2391,219)}
    [108] EMR_SMALLTEXTOUT                    (s=56) { TXT=[Grote Veldstraat 80] [exScale(8.464966) eyScale(8.461978) iGraphicsMode(1), Bounds(0,0,0,0)] TxOPT[fOptions(768=), nChars(19), ptlRef(2113,181)]}
      [075] EMR_EXTSELECTCLIPRGN                (s=16)  {iMode(5=RGN_COPY), RGNDATA[ptr:0x00e128b0, size:0, box()]}
    

    Image with the problem: http://img64.imageshack.us/img64/7540/problemsmalltextoutwith.jpg

     

    It would be great if we could find a solution for this rendering problem.


    Thanks!

    Monday, November 8, 2010 3:43 PM

Answers

  • Hi,

     

    Per the literal of your request, and per the review of GDI and EMF folks, I suspect that that you are experiencing a rendering issue with your viewing component. The image you referenced in your original post is the output of your rendering component. There is not enough detail or evidence to conclude anything about the problems your output renderer might be experiencing.

     

    Nonetheless, the fact that the metafile document is rendered properly by other viewers suggests that the issue resides in the component you are using. I think the EMF records are correct and the playback to graphics devices should work.

     

    I also understand you have been exploring the possibility on supplying your rendering component with EMF records that you know it would render correctly. In case this helps, you can convert an EMR_SMALLTEXTOUT record to an EMR_EXTTEXTOUT record. In the following, I will briefly explain how Windows GDI could do this, but keep in mind that this is beyond the scope of open specifications documentation.

     

    EMR_SMALLTEXTOUT is a simplified EMR_EXTTEXTOUT.  When GDI plays the EMR_SMALLTEXTOUT record, it calls ExtTextOut. Even though EMR_SMALLTEXTOUT has more fields (e.g. x, y , cChars, fuOptions) than EMR_EXTTEXTOUT, none of the parameters or information is lost from the EMR_SMALLTEXTOUT.  The only thing that is challenging is how to factor in exScale and eyScale.  Basically if iGraphicsMode is not GM_ADVANCED, then you need to create a world transform using exScale and eyScale. This will be a logic in the following lines:

    1)      If iGraphicsMode is NOT GM_ADVANCED:

    a)      Set iGraphicsMode

    b)      Set the font transform xform using the exScale and eyScale.

    2)      If ETO_SMALL_CHARS bit of fuOptions is enabled, convert string from 7-bit ASCII to Unicode

    3)      Call ExtTextOutW() with (ETO_NO_RECT|ETO_SMALL_CHARS) stripped from the options flags.

     

    References:

    [MS-EMF]: Enhanced Metafile Format

    http://msdn.microsoft.com/en-us/library/cc230514(v=PROT.10).aspx

    2.3.5.37 EMR_SMALLTEXTOUT Record

    2.3.5.7 EMR_EXTTEXTOUTA Record

    2.3.5.8 EMR_EXTTEXTOUTW Record

    Windows GDI

    http://msdn.microsoft.com/en-us/library/dd145203(v=VS.85).aspx

    ExtTextOut Function

    http://msdn.microsoft.com/en-us/library/dd162713(VS.85).aspx

    Font and Text Functions

    http://msdn.microsoft.com/en-us/library/dd144821(v=VS.85).aspx

    Metafile Functions

    http://msdn.microsoft.com/en-us/library/dd145052(v=VS.85).aspx

    Windows GDI+

    http://msdn.microsoft.com/en-us/library/ms533802.aspx

    SetGraphicsMode Function

    http://msdn.microsoft.com/en-us/library/dd162977(VS.85).aspx

     

    I hope this helps.

     

    Regards,

    Edgar


    Edgar
    Wednesday, November 10, 2010 10:11 PM
    Moderator
  • Hi,

    The information I provided you is not meant to define the records or any processing rules.  This was just an informative note in case it may help you in your implementation. Like I mentioned in my previous communication, this is out the scope of the specification documentation.

    Since other viewers can render preperly your metafile document, the EMF records appear to be correct. The best prescription we can give on this issue is that you focus on fixing your rendering component. Please feel free to try other alternatives that may work for you.

    Regards,

    Edgar


    Edgar
    Friday, November 12, 2010 10:08 PM
    Moderator

All replies

  • Hi wst_

    Thank you for your question.  Someone from our team will follow up with you asap.


    Regards,
    Mark M
    iller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEA
    M

     

    Monday, November 8, 2010 5:01 PM
  • Thanks Mark.

    I'm ready for the answer :)

    Tuesday, November 9, 2010 8:09 AM
  • Hi wst_

    Thank you for your question.  Someone from our team will follow up with you asap.

     


    Regards,
    M ark M
    iller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEA
    M

     


    Mark,

     

    Does a person of your team already had a look at it? (actually now it's blocking some of our work a bit :s)

     

     

    Kind regards,

     

    wst_

    Wednesday, November 10, 2010 7:43 AM
  • As I understand it, you're experiencing mis-rendering. It is not specific to the text alignment, and the document is rendered correctly by other viewers. So this is likely a bug in your code.

    My experience with implementing EMF is that the hard part to get right is the coordinate transformations. I'd double check that you are applying the bounding in device units (not in page-space or world space). Other than that, its going to be pretty hard to debug unless you can show the code.

    Good luck.

    Brad

     

    Wednesday, November 10, 2010 9:54 AM
  • Dear Brad,

     

    We are not generating the EMF.

    We receive an EMF and give it to another component that renders the EMF (FYI it's not our component that renders it, we can't make adjustments in their code).

    Here is our part: The rendering is not good, so we want to adjust one or more EMF Records to something that we know (by experience) that the other component renders correctly.

    In order to change one or more records to have a correct output, we need to know what is is going wrong with the records posted earlier in this topic.

    Here is a little movie that shows the problem .

    We loaded the EMF and zoom in and out on the preview.

    As you can see on the right side the bounding boxes seems to be OK because they are always cut off on exactly the same place.

    It looks like the font is not scaled correctly withing the bounding box when we adjust the scaling (zoom in/zoom out)? (Or character-spacing?)

    When we open the EMF that we receive in (for example) Paint, we see that the image is OK (because its size is 1:1, no scaling happend).

     

    I hope this information could help you.
    We really need to find out what is causing this problem and how we can change the record(s) causing us this problems.

     

     

    Kind regards,

     

    wst_

    Wednesday, November 10, 2010 1:10 PM
  • Hi,

    I have been researching this and will be providing a feedback shortly.

    Thanks,

    Edgar


    Edgar
    Wednesday, November 10, 2010 4:54 PM
    Moderator
  • I hope the Microsoft guys can help you, but I think this problem is pretty difficult unless you can constrain it in some way.

    Given the situation that you are describing, where you have an arbitrary EMF source file, and an output renderer with uncharacterised bug(s), I can't see any transformation at the record level that can ensure that the source file will be rendered as the originator intended.

    The source of the problem appears to be the renderer, but I guess you wouldn't be here if the vendor of that product was willing to help.

    The only way I can see that you can deal with this problem is to convert it to some other format that is rendered correctly (either a raster format like PNG, or if scaling is important then perhaps something like Postscript, PDF or a non-layout format like ODF or RTF).

    Good luck.

    Brad

    Wednesday, November 10, 2010 8:43 PM
  • Hi,

     

    Per the literal of your request, and per the review of GDI and EMF folks, I suspect that that you are experiencing a rendering issue with your viewing component. The image you referenced in your original post is the output of your rendering component. There is not enough detail or evidence to conclude anything about the problems your output renderer might be experiencing.

     

    Nonetheless, the fact that the metafile document is rendered properly by other viewers suggests that the issue resides in the component you are using. I think the EMF records are correct and the playback to graphics devices should work.

     

    I also understand you have been exploring the possibility on supplying your rendering component with EMF records that you know it would render correctly. In case this helps, you can convert an EMR_SMALLTEXTOUT record to an EMR_EXTTEXTOUT record. In the following, I will briefly explain how Windows GDI could do this, but keep in mind that this is beyond the scope of open specifications documentation.

     

    EMR_SMALLTEXTOUT is a simplified EMR_EXTTEXTOUT.  When GDI plays the EMR_SMALLTEXTOUT record, it calls ExtTextOut. Even though EMR_SMALLTEXTOUT has more fields (e.g. x, y , cChars, fuOptions) than EMR_EXTTEXTOUT, none of the parameters or information is lost from the EMR_SMALLTEXTOUT.  The only thing that is challenging is how to factor in exScale and eyScale.  Basically if iGraphicsMode is not GM_ADVANCED, then you need to create a world transform using exScale and eyScale. This will be a logic in the following lines:

    1)      If iGraphicsMode is NOT GM_ADVANCED:

    a)      Set iGraphicsMode

    b)      Set the font transform xform using the exScale and eyScale.

    2)      If ETO_SMALL_CHARS bit of fuOptions is enabled, convert string from 7-bit ASCII to Unicode

    3)      Call ExtTextOutW() with (ETO_NO_RECT|ETO_SMALL_CHARS) stripped from the options flags.

     

    References:

    [MS-EMF]: Enhanced Metafile Format

    http://msdn.microsoft.com/en-us/library/cc230514(v=PROT.10).aspx

    2.3.5.37 EMR_SMALLTEXTOUT Record

    2.3.5.7 EMR_EXTTEXTOUTA Record

    2.3.5.8 EMR_EXTTEXTOUTW Record

    Windows GDI

    http://msdn.microsoft.com/en-us/library/dd145203(v=VS.85).aspx

    ExtTextOut Function

    http://msdn.microsoft.com/en-us/library/dd162713(VS.85).aspx

    Font and Text Functions

    http://msdn.microsoft.com/en-us/library/dd144821(v=VS.85).aspx

    Metafile Functions

    http://msdn.microsoft.com/en-us/library/dd145052(v=VS.85).aspx

    Windows GDI+

    http://msdn.microsoft.com/en-us/library/ms533802.aspx

    SetGraphicsMode Function

    http://msdn.microsoft.com/en-us/library/dd162977(VS.85).aspx

     

    I hope this helps.

     

    Regards,

    Edgar


    Edgar
    Wednesday, November 10, 2010 10:11 PM
    Moderator
  • Edgar A Olougouna,

     

    Thanks for your reply and your explanation about the records!! (maybe this additional information about the records is something that could be added to the msdn documentation)

    We are checking your reply (I guess we will have an answer after the weekend if it worked for us or not).

     

    Kind regards,

    wst_

    Friday, November 12, 2010 3:31 PM
  • Hi,

    The information I provided you is not meant to define the records or any processing rules.  This was just an informative note in case it may help you in your implementation. Like I mentioned in my previous communication, this is out the scope of the specification documentation.

    Since other viewers can render preperly your metafile document, the EMF records appear to be correct. The best prescription we can give on this issue is that you focus on fixing your rendering component. Please feel free to try other alternatives that may work for you.

    Regards,

    Edgar


    Edgar
    Friday, November 12, 2010 10:08 PM
    Moderator