RE: WP file headers and DPSpool

DPSpool doesn't really care whether the WP file header is there or not.
If there are WP codes in the header that DPSpool recognizes (such as
margin setting codes, etc.), it will apply them. If there are other WP
codes in the header that DPSpool doesn't recognize, it should simply
ignore them.

My standard operating procedure with DPSpool reports is to have the
report initially configured to go to C:\NUL. Then I redirect the output
to the desired print job file within the report. Using this method, any
WP header auto-generated by DP gets sent to NUL and tossed out before
the print job file gets created. So it's really immaterial to DPSpool
whether DP creates a WP file header or not.

Since having a WP file header is important to users creating merge
files, I'm very much in favor of whatever works for them.

On a related note: There is a long-known WP-format bug in 2.6x that
prevents a ^N code at the end of a line from working properly. When
found within a line, ^E ^R and ^N should all be bracketted by hex E1.
This is working properly now. However, when one of these codes comes at
the very end of a line there should be no bracketting around it so WP
can recognize it as a control code. ^E and ^R are being treated properly
in this way, but ^N is always bracketted. It would be good if Lew could
fix this.

Oh, and as for the <u>/<i> question, it would seem that a command line
parameter that let you choose which to output would be better than
having two separate versions of the program.

Tim Rude

----- Original Message ----- 
From: "Brian Hancock" <[EMAIL PROTECTED]>
To: "Dataperfect Users Discussion Group" <[email protected]>
Sent: Thursday, June 12, 2008 10:44 PM
Subject: Re: [Dataperf] New version of DP on the horizon...


> Hi Everyone,
>
> Thanks for the input, I passed over each of the email I received to
Lew (for
> some reason he does not get the MailingList emails), and  this is his
reply:
>
________________________________________________________________________
_________
>  Hi Brian,
>
> Thanks for being the focal point of all this -- I know it has taken a
lot of
> your time.
>
> I'm not sure how to handle the underline / italics problem.  Adding
italics
> would be a lot of work.  I think for now I'll just hand out two
versions -- 
> and users can take their pick!  I guess I'll call these DP6YU and
DP6YI.  If
> you have them both, you can feel free to distribute them.  I'll send
copies
> of them to you and Ralph Alvy later on -- right now I'm very tired and
I
> don't want to make a mistake, so I'll wait a day.
>
> I'd like to fix the bug Charles Wolf has asked about -- the WP format
mode
> that puts out the bad header.  I added this code because Tim Rude uses
it
> for spooling DP output to a printer, and it is heavily used.  (I
think.)  I
> will gladly change it, but I'm not sure what it needs to be.  Perhaps
Tim
> knows more about this -- can he tell me what's wrong?
>
> In a couple of trial versions I added the "delete panel data" as an
option
> and in general it didn't perform any better than a subreport to delete
the
> data.  The only speed improvement is for the cases where you have
totals
> and/or refential integrity interactions; in those cases if I delete
the data
> with no interaction, it is much faster and not possible to duplicate
in a
> report.  If there are no panel to panel interactions and no text
fields, the
> data file can just be deleted and the associated index blocks simply
made
> available.
>
> My intial reaction is that this is a dangerous option and not worth
making
> it part of DP since it takes up a lot of code space real estate.
>
> The other option of deleting all data in adatabase is cleaner and
actually
> takes up less space.  Since it is very fast and can't be duplicated in
> reports, it seems more useful.  However, I suspect few people would
use it.
>
> Right now my inclination is to leave these options out unless there is
some
> user that feels they are critically important.  DP is already very
complex,
> and I  don't want to add more complexity that doesn't have a high
payoff.
>
> As soon as I have my wits about me, I'll prepare a package and send it
to
> you.  As I said, feel free to send the versions to anyone that wants
them.
>
> Lew
> _________________________________________________
>
> On the subject of the output of either <u> or <i> to represent
underlining
> in a DP memo type field, rather than two independant versions (which
would
> create a fork in future development), I think that Danny has a good
point
> about the use of Italics.   On modern webpages you rarely see
underlined
> used as a text decoration, you generally only see bold or italic as
simple
> decoration;  the underline is usually reserved for hyperlinks.
Additionally
> the <u> has been deprecated in XHTML (probably for that previous
reason) and
> although all modern browsers accept it as an underline, it is
generally
> better to use CSS to style underlines, which means that if someone
> desperately wanted an underline and all DP was producing was  <i> it
would
> be a simple matter to render that text as underline and not italics.
>
> I have done a fair bit of testing, and everything seems ok to me,
however I
> do not use DP in the myriad of ways other would use it, so if you
would like
> to test this version please send me an email and I will send it to
you.
> [EMAIL PROTECTED] and Lew will send the final release in a few days.
>
> For anyone producing HTML, XHTML or XML I think you will find this
version
> very worthwhile. For anyone using any type of scriping with DP you
should
> find this version invaluable.
>
> Regards
> Brian
>
>
>
>
>
> _______________________________________________
> Dataperf mailing list
> [email protected]
> http://lists.dataperfect.nl/mailman/listinfo/dataperf

_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf

Reply via email to