× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I'm pretty sure that AHPP is only intended to affect the horizontal
position, not the vertical position.  It stands for "Absolute Horizontal
Presentation Position"

I was looking in the book that Dietmar Buerkle posted the link for
yesterday (Thanks Dietmar!).  "IPDS and SCS Technical
Reference" by IBM , on page 207, under "Cursor Controls / Presentation
Position" it says:

    "Absolute horizontal moves to the left of the current cursor position
     are allowed.  If they are used the cursor is offset two pels to
     produce bold printing if characters are overstruck."

So, if you printed some text, and did an AHPP back to the start, then
printed that text again, it would be bold.   But what if, on the second
pass, you printed something else?   Such as dashes to make it look as if
you were crossing a word out?   Does PDF have the ability to print one
character on top of another?


On Wed, 13 Mar 2002, James Rich wrote:
>
> > Function scs2pdf_ahpp in scs2pdf.c doesn't handle positioning right,
> > if *curpos is lower then position. Wenn you make a report with
> > HIGHLIGHT attribute, AHPP is used to position the cursor back to the
> > start of this field and overprint a second time, to get a bold output.
>
> Hmm... I thought that if the current position is greater than the position
> given by AHPP (that is what the patch says, contradicting what you say
> above) that the printer should go to the next line and move over to the
> position indicated.  I'll reread that documentation.
>
> I'll think about how to get bold output.  It really shouldn't be too hard.
> If the behaviour you describe is what is supposed to happen then maybe we
> can know which characters are supposed to be in bold.  The only trouble is
> if we get the bold attribute (meaning AHPP go back and retype) after the
> characters that are supposed to be bold and we have already flushed the
> buffer we might be in a tricky spot.
>
> If AHPP is less than the current position and we are supposed to retype
> the characters for a bold effect, that does mean that the characters
> received after AHPP are the same as the characters received just before
> it?
>
> > I found no easy way, to switch to and back from a bold font, but
> > the following patch should at least print the second string in the right
> > place:
>
> Okay, I'll review the docs and see if they agree.  With this patch do your
> printouts look right?
>
> James Rich
> james@eaerich.com
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.