Re: Greek letters in the EMF terminal

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 16 September 2009 10:26:37 Benjamin Lindner wrote:
> Ethan Merritt wrote:
> > On Wednesday 16 September 2009, Benjamin Lindner wrote:
> >> Ethan Merritt wrote:
> >>> So far as I know, the EMF terminal works fine.
> >>> The big problem we have is that some [all?] versions of Windows
> >>> have difficulty viewing them.   
> >>>
> >> If I do the following change
> >>
> >> diff -r 0cb8214be97a term/emf.trm
> >> --- a/term/emf.trm	Wed Aug 26 16:14:37 2009 +0200
> >> +++ b/term/emf.trm	Wed Sep 16 16:26:48 2009 +0200
> >> @@ -1496,7 +1496,7 @@
> >>   	    }
> >>   	    EMF_write_long(strlen(str)); 	/* true number of characters */
> >>   	    EMF_write_long(76);			/* offset to text */
> >> -	    EMF_write_long(ETO_NO_RECT);	/* ExtTextOut options */
> >> +	    EMF_write_long(0);	/* ExtTextOut options */
> >>   	    EMF_write_rectl(0, 0, 0, 0);	/* bounding, never used */
> >>   	    EMF_write_long(0);			/* offset to intercharacter spacing array */
> >>   	    for (i = 0; i < len; i++)
> >>
> >> then it suddenly *does* work for me. No idea why, though.
> > 
> > That's a huge help (though a total mystery).
> > How did you think of changing that write in particular?
> 
> :) I saw that calls to EMF_put_text() succeeded, but calls to 
> ENHemf_FLUSH() not. And though the comment in ENHemf_FLUSH() states that 
> the particular section is copied from EMF_put_text(), it actually 
> differs in this particular write. So I just tried and it worked.
> 
> > Microsoft Developer Network documentation states:
> > 	ETO_NO_RECT: This bit indicates that the record does not 
> > 	             specify a bounding rectangle for the text output.
> > 
> > And in fact we don't provide one (see 2 lines below "never user").
> > 
> 
> Yes, I read this, and it got me confused, and I began to wonder if 
> "don't provide" and "write a record as all-zeros" is the same.
> 
> The reference to the ETO_NO_RECT in 
> http://msdn.microsoft.com/en-us/library/cc230599%28PROT.13%29.aspx
> states
> 
> "If ETO_NO_RECT is set in the fuOptions field, the Bounds field is not 
> included in the record."
> 
> This sounds more like the Bounds fields is not present, not simply 
> specified as all-zero. And indeed 
> http://msdn.microsoft.com/en-us/library/cc230599%28PROT.13%29.aspx:
> 
> "Bounds (16 bytes): An optional, 128-bit  WMF  RectL object ([MS-WMF] 
> section  2.2.2.19) that specifies the bounding rectangle in device 
> units." (for the EMR_SMALLTEXTOUT Record) and
> 
> http://msdn.microsoft.com/en-us/library/cc230576%28PROT.10%29.aspx:
> "Rectangle (16 bytes): An optional WMF  RectL object ([MS-WMF] section 
> 2.2.2.19) that defines a clipping and/or opaquing rectangle in logical 
> units." (for the EMRTEXT Record)
> 
> In both cases it's an "optional" Rectangular object. So I wonder whether 
> specifying ETO_NO_RECT means that this particular Rectangular clipping 
> object is to be omitted from the EMF file.

If so, it's strange that the current version works in any viewer at all.
I should think that getting the record length wrong would break the
linux and OpenOffice implementations as well as the Windows implementation.
On the other hand, there is an explicit offset field.
Maybe the bug is that the Windows implementation doesn't pay attention to
the offset field, and instead walks through the number of records it expects
to read?  That would fit the observed behavior, I think.

Ah well, an empirical fix is better than no fix at all.
I'll make the change in CVS and hope it gets some testing via the
4.4 release candidate.  



-- 
Ethan A Merritt