• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

RFC: A pretty-print processor?

Started by warpcafe, 2009.09.02, 13:47:19

Previous topic - Next topic

RobertM

Thomas,

What about Apache's pdf mod? Can't that simply be used with html as the input method?

Best,
Rob


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


warpcafe

Hi Robert,

...but that would require an Apache server to be installed, wouldn't it?
Sounds to me like a bit "too much" ...just for creating PDFs from rexx ;)

Cheers
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

RobertM

#17
Quote from: warpcafe on 2010.07.23, 08:54:57
Hi Robert,

...but that would require an Apache server to be installed, wouldn't it?
Sounds to me like a bit "too much" ...just for creating PDFs from rexx ;)

Cheers

Apologies Thomas, I was actually talking about AMP and not Apache - substitute Apache for PHP, in which case I am talking about PHP5's PDF Module, and not Apache's.

Was in the middle of a buncha things when I made that post, and mangled together my thought, thusly writing the wrong AMP daemon in my earlier post.

Now... other than the facts that
- there is PDF support in the AMP package
- Even on OS/2, that support (assuming it's what is being used) works (tested via a Joomla install)
- There is a PDF dll located in PHP5/modules (named pdf.dll)

Not sure if PHP based things like Joomla are using the PHP DLL and not Apache's support.

I am also not sure if it came in Paul's PHP build, or I downloaded it from here:
http://os2ports.smedley.info/index.php?page=php-5

Regardless, as Paul did release it, I presume it is functional (especially if it's the PDF module that Joomla is calling - in which case I can confirm it's functional). That may mean it would be the ideal place to start.

I suspect that this may be a help (cant yet find more docs, but not much time to look - most I have found are ones about issues running it on Windows so far):

http://articles.sitepoint.com/article/generate-pdfs-php




Otherwise, PDF documents can be done the "hard way" directly in REXX - but would conform to a very old PDF spec. I've done this in the past, by creating simple PDF documents and saving them in an ancient format, removing the header and footer (to reuse later), creating content to place between the header and footer, then outputting the end result. It is not the prettiest way, but it works in a pinch. For most any document.

Following the PDF specs online (at Adobe's site I think - haven't looked at them in a while), there doesnt seem to be anything too complex to prevent REXX itself (as a last resort) from creating PDF files in actual scripted code, which can follow along your guidelines.




There's also the PDF tool in Igor Pool's RexxWeb package, which works decently, but does not support any page orientation other than portrait or anything other than one page size. I have found, by converting the document to a different "orientation" (in actuality; swapping the page size AFTER document creation), that I can create documents in both portrait and landscape. A similar thing can be done to create different sized documents. His PDF tool does not seem to care about creating document elements outside of the document's bounding box - it still writes them to the "file" (rexxvar).

Problem is, it does not support images.

Best,
Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

PDF Specs are located here:

http://www.macrolearn.com/devnet/pdf/pdf_reference_archive.html

Seems PDF sample at the page I indicated below does not work, even though PHPINFO says the PDF DLL is loaded. I get an error stating it is unable to find function (exact error in bit).

Best,
Robert



|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


jep

Hi warpcafe,

Quote from: warpcafe on 2010.07.19, 23:42:47
Hej Jep,

Quote from: jep on 2010.07.17, 21:17:18
Can you please therefore also write down some initial thoughts of how to call the rexx funtions to use with parameters, what they should do and mean etc.

that's easy as duck soup. OK, so you want some details?
This is what I need the DLL to do in its first release:
Note 1: No error-handling implicitly described. Obviously, each function should set an RC variable...
Note 2: All of the below is available in PdfLib 7 AFAIK ...and also part of any standard "printer object" API... more or less "flavored"...

pdfLoadFuncs()
one only has to pass the calls to functions in the library "PDFlib Lite 7", to do that?

Please provide the link to the actual library again.
...
Quote from: warpcafe on 2010.07.19, 23:42:47
Well, that's all I need for the first round. :)
- text justification stuff can be easily figured out by using pdfTextWidth and pdfSetCurrPos
- no line feed stuff needed in first round, this can be programmed by using pdfSetCurrPos
- no watermark or signature or hyperlink crap needed now
- almost everything basic is feasible with these functions

Hope I was able to somehow explain what I meant.
Cheers,
Thomas
Very well thought out I must say.
I can therefore look a bit beyond since you've specified all of that...

How should each function behave when the user doesn't follow the exact schoolbook example?
e.g. one doesn't want to provide all the info, in the function pdfStartDoc( title, author, comments, keywords ).
How should it handle situation where the user just provide 1, 2 or 3 of the parameters?

What if no parameter will be provided?
Should it return a list of taken handles then?

Can we reuse some of the functions to behave differently if the input contain fewer/more parameters?
e.g. return information in some situations, default to something (next "row") etc.

Should some functions allow for input of stems as well?
Especially those functions that contain coordinates.

Possible to manipulate more than one PDF at the time as you indicate that the function pdfStartDoc( title, author, comments, keywords ) should return a handle?
Should the user be able to specify an associated "name" for the handle as an option as the actual handle anyway will be passed around internally by the rexx library?
(rexx only use plain text to represent variables, so "handles" and other non-integer/non-character parameters has to be either converted or associated with a "name")
pdfStartDoc( title, author, comments, keywords[, doc_handle ] ) RETURNS doc_handle

Let's say the script take a long time to complete adding data because it wait for information from ... somewhere.
Does the underlying library allow that or should all data be provided before the actual output?
If so, can you add a pdfPrint( doc_handle ) or pdfCreate( doc_handle ) that does the actual printout/creation.

Paper Size?
Do we always assume A4 and in Portrait mode?

//Jan-Erik

RobertM

Quote from: jep on 2010.07.25, 17:46:02

Paper Size?
Do we always assume A4 and in Portrait mode?

//Jan-Erik

I personally would prefer not - paper size should be customizable... sotmeplace). A4 will cause all sorts of problems in the US, as I suspect that Letter would elsewhere. Many printers will hang on an A4 page, waiting for the user to put A4 sized paper into it (they are generally configured for Letter or Legal in the US - never seen A4 as a default). And in OS/2's case, often the print queue will just hold on to the document forever (Or until the printer settings are changed and A4 is loaded into it) with either a "Document mismatch" or "forms mismatch" error.

It should be very easy to create a small list of A4, Letter, Legal, non-US Legal size, maybe a few envelope sizes, etc that the user can then call by name. For instance (sizes totally made up because I am too lazy to look them up right now):

paper.Letter="320,480"
paper.A4="310x492"

etc...

Best,
Rob


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


jep

#21
Hello,

Quote from: RobertM on 2010.07.25, 19:18:37
I personally would prefer not - paper size should be customizable... sotmeplace). A4 will cause all sorts of problems in the US, as I suspect that Letter would elsewhere. Many printers will hang on an A4 page, waiting for the user to put A4 sized paper into it (they are generally configured for Letter or Legal in the US - never seen A4 as a default). And in OS/2's case, often the print queue will just hold on to the document forever (Or until the printer settings are changed and A4 is loaded into it) with either a "Document mismatch" or "forms mismatch" error.

It should be very easy to create a small list of A4, Letter, Legal, non-US Legal size, maybe a few envelope sizes, etc that the user can then call by name. For instance (sizes totally made up because I am too lazy to look them up right now):

paper.Letter="320,480"
paper.A4="310x492"

etc...

Best,
Rob
In that case we need to specify the measurement unit to use
paper.label='A4'
paper.dimensions="210,297"
paper.units = 'mm'

or

paper.label='A4'
paper.dimensions="21,29.7"
paper.unit = 'cm'

etc.
but also

paper.orientation = 'Portrait' (default, can be set with anything that begin with P)
or
paper.orientation = 'Landscape' (can be set with anything that begin with L)


//Jan-Erik

warpcafe

Hi,

Quote from: jep on 2010.07.25, 17:46:02
one only has to pass the calls to functions in the library "PDFlib Lite 7", to do that?
...heck, how am I supposed to know? :-P
I only went thru the documentation halfway...

Quote
Please provide the link to the actual library again.
http://www.pdflib.com/en/download/free-software/pdflib-lite-7/   (PDFLib 7 Lite sources)
http://www.pdflib.com/developer/technical-documentation/manuals/   (PDFLib manuals, i.e. version 7)
http://hobbes.nmsu.edu/download/pub/os2/dev/pdflib302.zip  (port of -vintage- PDFLib 3.0.2 on hobbes)

Quote
How should each function behave when the user doesn't follow the exact schoolbook example?
e.g. one doesn't want to provide all the info, in the function pdfStartDoc( title, author, comments, keywords ).
How should it handle situation where the user just provide 1, 2 or 3 of the parameters?

What if no parameter will be provided?
Should it return a list of taken handles then?

Can we reuse some of the functions to behave differently if the input contain fewer/more parameters?
e.g. return information in some situations, default to something (next "row") etc.
Well, we can argue about the meaningfulness of making parameters mandatory if that comes at the price of having to deal with error-handling of missing mandatory parameters. :)
I prefer a very "relaxed" handling here: Something is missing or doesn't make sense? Use internal/override defaults! This means that if we have missing parameter values, the DLL will use an internal value where it makes sense.
(Of course, we cannot use "defaults" for print coordinates - this doesn't make sense - but for "author" we could use the literal "SYSTEM" or "NOT SPECIFIED" when missing. Same for title: "UNNAMED" or whatever.)

Keep in mind that the focus of this DLL would be the creation of PDFs - not the validation of syntactical and semantical correctness of parameters. ;)

Quote
Should some functions allow for input of stems as well?
Especially those functions that contain coordinates.
Keep it simple and stupid! ;)
I don't think stems are required at this point... if you have a list of coordinates, you would have to iterate it and pass one x/y pair at a time.

I prefer simple function syntax and greater flexibility. I hate the unix'ish style of making things more and more complex because it shows how cool you are "Hey, look what I can do with *1* call only, if I use these 475 parameters along with it!".
That crap was introduced by spot-faced, highly intelligent nerds which have the time to explore and tweak 1 algorithm over 4 weeks...(because they don't have girl friends) -  but not by people who have to solve programming tasks in a quick and easy way.

Quote
Possible to manipulate more than one PDF at the time as you indicate that the function pdfStartDoc( title, author, comments, keywords ) should return a handle?
Should the user be able to specify an associated "name" for the handle as an option as the actual handle anyway will be passed around internally by the rexx library?
(rexx only use plain text to represent variables, so "handles" and other non-integer/non-character parameters has to be either converted or associated with a "name")
pdfStartDoc( title, author, comments, keywords[, doc_handle ] ) RETURNS doc_handle
Well, when I said "handle" I had an integer value in my mind which is used for reference between rexx and the DLL. Do as you please. A name? Sounds good. I'll take what I can get as long as it does what I want. ;)

Quote
Let's say the script take a long time to complete adding data because it wait for information from ... somewhere.
Does the underlying library allow that or should all data be provided before the actual output?
If so, can you add a pdfPrint( doc_handle ) or pdfCreate( doc_handle ) that does the actual printout/creation.
Oh, pretty easy:
We have to distinguish between
- sending commands to the DLL
- writing of a PDF file
- sending something to a printer
Output on paper is clearly out of scope. The solution creates a PDF file.
First, we send a couple (or bunch) of commands to the DLL. The DLL internally creates a "context". Imagine this like a in-memory representation of a picture. This picture has one or more pages containing text and graphics. This context is open and available until the PC crashes, the DLL crashes, or the document is closed.
Once the document is closed, the DLL will start writing the PDF file to disc.

Quote
Paper Size?
Do we always assume A4 and in Portrait mode?

No, we don't assume anything.
"Unfortunately" this will be in the responsibility of the rexx-developer using the DLL. We will write a manual explaining how to create a PDF that fits A4, legal, whatever... and perhaps we can "tailor" some mnemonics for simple useage, but basically (technically-speaking) the DLL will create a document based on the paper size specified by height and width. Which units to use - I don't know. Points? Inches? Millimeters? Perhaps the unit to be used can be specified? Not sure what PDF uses internally.

We could do two functions that create a document:
- PDFStartPage (Size, Orientation) -> where "size" is "A4", "Legal", ...
  e.g. PDFStartPage("A4", "P") to create an A4 in Portrait Mode
- PDFStartPageEx (Unit, Height, Width, Orientation) to make it fully flexible
  e.g. PDFStartPageEx("MM", "297", "210", "P") to create an A4 in Portrait by millimeters

Hmm...  I guess we also need some function like
PDFSetPageMargins (Top, Right, Bottom, Left) ... or should we combine this as optional parameters (default: 1.5 cm) into the "StartPage" function? :-P

Error handling in general:
Each function should actually return a value to show if it was successfully executed or not.
Using this to check if errors occurred however is in the responsibility of the developer. If he/she doesn't check if some call went wrong - well, too bad. Example:


/* start document without using RC... */
call PDFStartDoc "My PDF", "Thomas", "no comment..."

/* start document WITH using the RC... */
myrc = PDFStartDoc("My PDF", "Thomas", "no comment...")


You know what I mean?
If this is too difficult to support, the DLL could also make use of a generic variable "PDFRC" which is provided automatically to REXX once the DLL is loaded. This RC will be updated with the respective return code on each function call like this:


/* start document and use internal RC... */
call PDFStartDoc "My PDF", "Thomas", "no comment..."
if PDFRC \= 0 ...


Glad you provided some feedback, cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

warpcafe

Hi all,

oh, by the way:
Leaving aside the PDFLib topic... does someone know how "difficult" it is to create a document by issueing commands to Ghostscript?
(Or to create a text-file which can be used by Ghostscript?)

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

Fr4nk

Well,

Quoteoes someone know how "difficult" it is to create a document by issueing commands to Ghostscript?
(Or to create a text-file which can be used by Ghostscript?)

what exactly you want GS to do for you?

GS can work with postscript and image files. So you could create a PS file with Rexx  and feed it into GS to print it or  make a PDF

But belive me you wont ;)

If you want to create PDF files you could use one of the TEX thingies. There are some interpreters which can interpret tagged assci files a to make PDFs. But imo that is a pain. We need a PDF lib which can be handled from Rexx using standard Rexx syntax or alternatively a Rexx DLL which gives us direct access to OS/2 print api. as it has been discussed here and suggested by you.

About the syntax topic my 2 cents:

1. missing parameters: don't add default values e.g. for  title or author. Just leave things blank.
Developer has to pass all parameters or leave it blank. E.g.
rc=function(first,,third)
So just leave it blank. Thats common Rexx usability.

if there is a "," missing there should be an error  (in return code rc)

2. Page sizes:

There should be page sizes in witdh and high. Imo in points.
I think there is no need to build in named sizes like "Iso A4", "letter" etc. This can be done by the Rexx developer  (no problem to include these things inside the Rexx script later. This keeps things open.

Btw very nice to see interest and how things going concretely here. PDF library for Rexx is something I'm missing a long time now.  It would be happy to help e.g. with tests or documentation or anything else if it reachs  this stage.


CDRWSel

I resolved missing print option under rexx by generating a html page and printing it from firefox into pdf.
Very easy to do.

jep

#26
Hello,

PDFLib seem to at least partially support Watcom... but could someone help me a bit to get it to compile.
And as always with Linux centric software, it's dependable on libraries that one probably has to compile and not reuse what's already there.

Would like if someone would have a moment and help me look at that as well.

//Jan-Erik

warpcafe

Hi,

Quote from: CDRWSel on 2010.07.26, 23:52:16
I resolved missing print option under rexx by generating a html page and printing it from firefox into pdf.
Very easy to do.

Yeah, but in this case, you could also print to a suitable XML, do an XSLT and get a PDF out of this without the need for having Firefox used. Don't you think this is a bit "oversized"... not to call it "overkill"... just for getting something printed pretty from rexx? Imagine I would want to write a small application for doing invoices. I have a GUI in rexx, I have sqlite connected to rexx... great.
But for printing I will tell the user "please use Firefox to print the generated HTML." ? ;)

No, no... while I appreciate that you shared your resolution, it is not an option for serious rexx development. The approach you described is tedious, not to mention the efforts for creating a well-suited HTML file - and that's exactly the reason why we need a way to to pretty-printing from native rexx, be it using a PDF generator DLL or a "printer object" DLL.

Anyway, thanks for sharing the information!
Regards,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

Fr4nk

#28
Quote from: CDRWSel on 2010.07.26, 23:52:16
I resolved missing print option under rexx by generating a html page and printing it from firefox into pdf.
Very easy to do.


I use such workarounds aswell in other situations.  But I think only hard boiled OS/2 users do such things :)
Its a bit like you want translate a text from German to English but you don't own a GER-ENG dictionary but you have a GER-SPAIN, a SPAIN-FRENCH and a FRENCH-ENG dict. . And then you translate the German text to Spanish, then from Sanish to French and finally from French to English. .  Its possible but a workaround for a lack of right tools.





warpcafe

Hi all,

yet another tidbit around this topic:
http://libharu.org/wiki/Main_Page

From what I read ("ANSI-C") it looks like it should compile on OS/2.
Not sure about the effort involved here... and which flavor of compiler to use preferrably.

Anyway, even if this works, it would "only" give us a DLL useable from C... right?
What would it take to create a rexx-to-HaruDLL "wrapper"... or a rexx-callable variant of the HaruDLL?

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy