Re: upside-down form elements?

[Hans Hagen <pragma@wxs.nl>]

[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]

Matthew Baker wrote:
> 
> On Tue, 1 Jun 1999, Hans Hagen wrote:
> 
> > Can you also test the travel form?
> 
> Same problem
> 
> > I encountered this problem with a form I made for Han The Thanh, but was
> > not able to trace it. Acro 4 is more troublesome than Acro 3. I reported
> > this bug several times to adobe, but it seems they didn't repair it.
> 
> I've been looking at the Postscript output.  Just before teach of my form
> elements there something like
> 
> 1 0 0 -1 162.73999 710.22999 cm
> 
> and this is causing the problem.    The -1 should be 1.  However this
> places the test above the box in which it is supposed to appear, ie
> Acrobat's PS converter seems to have intelligently been able to reposition
> the upside-down text.
> 
> > The interesting thing is that I do not do anything special, just normal
> > xforms and fields. Rather strange eh?
> 
> I have no doubt in my mind that this is an Acrobat bug, given that a) it
> looks fine in PDF and b) every version of reader I try seems to do
> something different (either printing upside-down text, not printing
> anything or plain not letting me type into the fields!).  The question is,
> is it a bug that can be worked around?
> 
> I haven't tried this in windows yet.  Will try to today (Windows machines
> here are much scarcer than Unix boxes).

The - sign is a cue. PDFTEX somehow has a opposite reference frame when
annotations (the pure ones) are concerned than for instance pdfmarks. I
have to feed the \pdfannot primitive with a negative value to compensate
for this. I would say, as long as the type is ok, the viewers should do
their job too.   

As said, I have encountered problems like yours before (it's one
bottleneck in some forms experiments with thanh) but indeed every viewer
acts different. 

I did some experiments, and found out that some box raising combined
with positive values solves the problem. 

Now, the strange thing is that this only affects the box being drawn,
there are (low level pdftex generated) x/y shifts involved, but no
rotation and scaling! So, actually this is a bug in the readers. By the
way, I did report the print problems to the beta program, I also
suggested them to reset the cm matrix at the start of each annotation,
but alas, problem not solved. 

I've attached a file, and I want to make sure field 2 and 3 print ok
everywhere, so whoever want to test on whatever platform ... 

I'll send the 2 line patch and the test.tex file to thanh and matthew
for further testing. (Matthew: you should change the macros in the
spec-tpd.tex driver (run time loaded, so no fmt generation needed). 

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

[-- Attachment #2: test.pdf --]
[-- Type: application/pdf, Size: 7500 bytes --]