OS2World OLD-STATIC-BACKUP Forum

OS/2 - SIGs => Rexx => Topic started by: warpcafe on 2009.09.02, 13:47:19

Title: RFC: A pretty-print processor?
Post by: warpcafe on 2009.09.02, 13:47:19
Dear all,

some time ago I started a poll about what people are missing when it comes to REXX on OS/2|eCS.
One of the more frequently opted things was the lack for doing "pretty" prints from REXX, so to say graphics printing and stuff.

Now I have played a little with the printer object available in VisualAge Basic.
(I must admit that my knowledge of programming languages for use in OS/2|eCS is limited to REXX and COBOL, while my "sweet spot" actually is Visual Basic on Windoze... that's why I considered VABasic...)

Well, it seems like my assumptions on VABasic's capabilities were met so far - it basically supports everything needed... but before I start the real work, I wanted to see whether people are interested at all. Here's what I intend to do:

To give you an example what would be feasible:

A better example - the whole stuff in that text file would function as talking to a printer:
" this document is A4 sized, in portrait mode "
" margins are 2cm top, 1.5cm bottom, 2cm left, 1cm right "
" use Arioso 12pt bold; at x=4.2cm and y=2.1cm print 'Hello ' "
" now use Helvetica, 48pt, underlined and print 'World!' "
" now go to x=5cm, y=10cm; use TimesNewRoman 10pt "
" right-align and print 'This' + newline + 'is a' + newline + 'right-justified' + newline + 'text.' "
" at x=12cm,y=20cm print 'c:\mystuff\sample.bmp' with width=1cm, height=1cm"
" done "

Of course there will be a way of specifiying whether you want to use centi-/millimeters or inches as unit in your current doument. However, I still have to investigate if twips, inches, points and centimeters... are processed "correctly"... ;)

Basically, this is more than enough to create documents like invoices and stuff...
As "advanced" features (perhaps at a later stage if enough interest is there) I could imagine things like forms and reports processing (using line templates, automatic loops, etc.).

As I said, it will not be a "DLL" usable from REXX but basically something batch-like. On the other hand, this would allow it to be used with almost anything since it only processes a pseudo page description. If someone with more experience than me tells me that it's possible to create DLLs with VABasic that can be loaded and used by REXX, I am more than willing to give it a try if he/she shows me hwo to do it.

Now for the drawbacks:
According to the readme, Visual Age for Basic has one serious limitation in its OS/2 version: There can be only 1 executable (created with VABasic) ran at given a time. This means that any other VABasic program will not run when there is already (or still) 1 VABasic program in memory.

(Holy moly, don't ask me why this is the case and how comes IBM released such a thing...)
Needless to say that VABasic seems to be unsupported abandonware. No fixes available AFAIK.

Another drawback is that "the crap" (sorry, ehh, Visual Age for Basic) will require a lot of runtime DLLs to work. But I don't consider this to be a huge problem, do you?

Finally:
I know there is Peter Kanis' print library still available (on Hobbes), but it seems to be abandonware (and shareware BTW) and IIRC "only" available for VX-REXX. If you ask yourself why I simply don't use OpenWatcom or WDSibyl or VAC++... the answer is: I don't know Pascal, Fortran, C or anything else you might consider more suitable. And yes - I could perhaps do it in NetREXX... but that would give us something running in JAVA. I doubt this could be used as a DLL for REXX... not to mention that Java isn't wuite my sweet spot either. ;)

So, what do you think? Is that something "we" could make use of?
Let me know what you think. Feel free to bother with questions.

Alternate solutions:
All my attempts to find someone who could do this in any flavor of "C" were unsuccessful so far. That's why I decided to give it a try with VABasic. If YOU happen to be an OS/2 developer and you know how to create REXX-usable DLLs and how to interact with a printer object (component), I can give you more detailed specs on how the stuff is intended to function and would gladly help you in testing, documenting and whatever else I feel able to do. Write me if you're interested. Don't expect any kind of payment though - and be aware that it's something intended to be open-source (or freeware at least).


Cheers,
Thomas
Title: Re: RFC: A pretty-print processor?
Post by: RobertM on 2009.09.02, 14:12:51
Sadly, a solution already exists. I used to have the source code and just needed to clean up a few things for it. Sadly, when I was moving from the DC area to here, the box with my archive CDs was stolen - along with the code. The code worked for both REXX and various visual REXX packages. It was written by Peter Kanis, who is the person who sent me the code (a version past what is floating around) when he decided he was unable to continue the project.

I will keep digging through the few archive disks I have remaining (about 20 out of 300) and see if I have another copy misplaced on a different disk. If so, I have no problems contributing it to the OS/2 community to a programmer who can finish or help finish any fixes it needs (Peter passed the license of it on to me).

Robert
Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2009.09.02, 14:32:53
Robert,

wow, would be great if you could find it!!
If not, would it be possible to ask Peter if he has some leftovers?

I mean - even if it would mean to redo all your work from scratch, it would still be better than having nothing at all.
(And, I must not forcibly be YOU - someone else could do the job as well...)

Also, this would allow me to concentrate on something different regarding VABasic development...

Cheers,
Thomas
Title: Re: RFC: A pretty-print processor?
Post by: RobertM on 2009.09.02, 15:01:09
Thomas, I will check. At the very least, an earlier version (v2.2 I believe) exists with source out there. Peter did a LOT of work since then, and I fixed a few remaining issues as well, but at least it is a starting point if I cant come up with the code for the later version, or he no longer has it (which is possible - he gave me the code 6 - 8 years ago).


Some issues I was trying to resolve were greater printer attribute selection/control. The advantage I had there (thank you IBM) was a lot of code for the new (at that time) print engine written for Warp 4 - everything from examples to some sources for the code actually in the print engine betas themselves (I've always wondered if somewhere in the code is my name for the tiny bit of work I did to get the GA engine debugged and working... but that's unrelated I guess).

And yeah, I would need some help with it. I havent done C++ programming in 6 or more years, and though I recently re-purchased VAC++, I have not had a chance to play with it.

Rob
Quote from: warpcafe on 2009.09.02, 14:32:53
Robert,

wow, would be great if you could find it!!
If not, would it be possible to ask Peter if he has some leftovers?

I mean - even if it would mean to redo all your work from scratch, it would still be better than having nothing at all.
(And, I must not forcibly be YOU - someone else could do the job as well...)

Also, this would allow me to concentrate on something different regarding VABasic development...

Cheers,
Thomas

Title: Re: RFC: A pretty-print processor?
Post by: jep on 2009.09.03, 13:34:34
Hi,

I would be very interested in that as well... in a couple of rexx-related projects that would  benefit greatly from it.

Side note:
I do know how to write rexx dlls, some basic C/C++ stuff but need help with OS/2 specific stuff.

//Jan-Erik
Title: Re: RFC: A pretty-print processor?
Post by: Fr4nk on 2010.02.20, 22:48:26
This sounds very interesting. Is there any progress in this project?

Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.02.24, 13:02:32
Hi all,

well no progress to my knowledge.
On a side-note, I was told that apparently Peter Kanis indirectly (not THAT public so to say) allowed for the free usage of his print library for Vx-Rexx which was previously distributed under a shareware license. That doesn't help with the current task, however I guess it's worth mentioning.
If I find time, I'll dig out the conversation and see who told me and perhaps I'll be lucky to get/find an official statement from Peter himself. That could also perhaps help in turning his work into an official "open-source" project at... what? Netlabs? os2world? Whatever.

For the VABasic stuff, well, I don't see any problems in doing it... however, when looking at all the implications (questionable if DLL can be done, runtime-requirements and limitations, ...) I would actually prefer to have someting "well-done" instead. I wouldn't even mind to set up a bounty and draft a technical document about how I believe it should be designed.

Basically - as a request for comments - it is not really rocket science: The library should have functions for loading, selecting a printer, specifying page properties, start and close a document and finally, leave all remaining stuff as a "transparent" set of functions that map to the actual methods (set current position, set font, print text, etc.).
I don't know how things are handled with using the PM-API from -say- C++ but: When I use VABasic, it gives me a "printer" object that supports various properties and methods. And I am qute sure that they didn't reinvent the wheel for VABasic, so I suppose there is some kind of mapping/wrapping around the "real" API created for VAB. Some abstraction and simplification logic may be involved for the convenience of a Basic developer to save him from having to deal with device contexts perhaps... but nevertheless, I still think that it should be basically possible to provide the printing "features" in the PM-API to a set of rexx-callable DLL functions without a "huge" effort.
Comments? Anyone here having C-skills and experience with printing in OS/2|eCS ?

Regards,
Thomas
Title: Re: RFC: A pretty-print processor?
Post by: Fr4nk on 2010.02.24, 14:11:58
Well my personally point of view is this:

Good thing would be a rexx dll which works on plain rexx. So everyone can use it everywhere, anyway hes using VX  or Vispro or just plain Rexx. This would be important to use this DLL in existing programs.

It could be done by this Thomas already posted, but here is another idea:

Why not porting one of the PDF libraries into a Rexx dll?  Advantages would be:

- we could create PDF files directly from Rexx
- we don't need to handle any special printer stuff
- any PDF reader (Acrobat, Lucide) could be used to print, and a as a really nice side kick these application show the PRINT PREVIEW so there is no need to develop a print preview for itself.
- you can print PDFs in every copyshop around the corner in case you need color or high quality or quantity prints
- unlike other existing tagged-text-to- PDF processors like Tex such a solution could be integrated very well into stand alone Visual Rexx applications.

So far I know there a several PDF libs avi for web services etc.. I have no idea what it means to turning  such a thingy into a Rexx DLL but maybe someone is able to have a look at it.

I think it would be enough to have basic things like printing text and simple geometric figures and bitmaps. No need for all this multimedia stuff Adobe applied to PDf format.


Title: Re: RFC: A pretty-print processor?
Post by: jep on 2010.02.24, 15:50:47
Hi,

create a dll that does the things you mention... so that specific dll can be used in C/C++ or use some existing project/dll.

Then create a DLL for rexx that load the first library and call the appropriate functions the way one can expect to use rexx functions.

That's way we get the best out of them, much easier to write the code as one doesn't have to deal with *nix specific stuff if you're only interested to get a proper rexx interface.

I've done just that with rxGBMSize, rxODBC etc.

//Jan-Erik
Title: Re: RFC: A pretty-print processor?
Post by: Fr4nk on 2010.02.24, 16:02:25
Quote from: jep on 2010.02.24, 15:50:47

I've done just that with rxGBMSize, rxODBC etc.


is this an offer or notice of intention? ; ;) 8) ::)
Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.07.17, 15:53:18
Hi all,

so what's the state here?
Recently I came across an article in a web developer magazine about PDFLib and what one can do with it. Nice. I then went to the site at www.pfdlib.de... it says

Quote
The PDFlib Lite 7 source code package contains C source code, support files for the C, C++, Java, Perl, PHP, Python, Ruby, and Tcl language bindings, the PDFlib tutorial and API reference manual, as well as samples for all supported languages. Please see here for a sparate download of the documentation.

Sounds good, right?
What I would need is a sort of pdflib that can be called from OS/2-rexx (native, classic or OO.. whatever).

We have an older port of pdflib (v.3) already on hobbes and there are even the "free" sources of PDFLib 7 Lite. We simply lack something painlessly useable from OS/2-rexx just like we do with the other rexx-DLLs we mostly use.

Ain't there any skilled person here who could craft a rexx-enabled DLL from that?

Cheers,
Thomas
Title: Re: RFC: A pretty-print processor?
Post by: jep on 2010.07.17, 21:17:18
Hello,

warpcafe, provide a link to the package and how/what the rexx dll should do.

We may want to discuss what functions should be provided and how do those things in rexx.
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.

I can give you (all, and not only Thomas/warpcafe) hints how to write the C/C++ code for the rexx dll.

It should be fairly easy and not take that much to write the rexx functions with OpenWatcom as it provide a GUI for the compiler.
The problems may be if you come up with ideas of new wild things to do ;D

//Jan-Erik
Title: Re: RFC: A pretty-print processor?
Post by: Raiko on 2010.07.17, 23:42:58
Warpcafe, perhaps the result of this project could be something I could use for printing invoices
from Concorde since it has the option to print to "text file". However, in this case I would need a
procedure that "automates" the production of the invoices.

......and if it also would save copies as pdf and possibly email invoices as pdf attachements to
some customers ...... ::)



Title: Re: RFC: A pretty-print processor?
Post by: 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()
- Loads the library and makes all functions available to rexx.

pdfDropFuncs()
- obvious, eh?

pdfStartDoc( title, author, comments, keywords ) RETURNS doc_handle
- starts the print job, sets the document information accordingly to the parameters (all optional except "title" BTW)
- The doc_handle enables creating more than 1 PDF doc at the same time...

pdfEndDoc( doc_handle )
- ends print job for the document specified by "doc_handle"
- this is when the output to the "print device" starts

pdfStartPage ( doc_handle, [ height, width] | [ pagesize, orientation ] )
- creates a blank page in the document specified by "doc_handle" at the end of the page list
 (or, to put it like this: It appends a new page in the doc)
- syntax 1: creates a page by specifying height and width in "dots" or whatever unit is supported in PDF (don't know)
- syntax 2: creates a page by specifying a mnemomic like "A4", "legal", ... and whether it's "landscape" or "portrait"
- the new page becomes the "current" page (the one that receives all text and graphics output)
- the previously "current" page (if any) is implicitly "closed" (also see "pdfEndPage below)
- the internal page counter is incremented

pdfEndPage ( doc_handle )
- closes processing for the "current" page
- Comment: This would mostly be used only for the last page in the doc since pdfStartPage() closes a previous page implicitly
 (in your code, you would only "start new pages" and explicitly "close" only the last one before using pdfEndDoc...)

So, these were the "bones" - here is the "flesh":

pdfLoadFont ( fontname ) RETURNS font_handle
- makes a known, installed font available. "fontname" is an alias-like name, e.g. "Helvetica"

pdfLoadFontFile ( filename ) RETURNS font_handle
- loads a font by specifying the font file name, e.g. "COURBD.TTF" (if TTF supported - don't know) or "HELVB.OFM"
- Note: I don't know enough on how Acrobat handles fonts (or font files). PLease bear with me
- Note: I don't have OS/2 or eCS at hand. Sorry if the postscript font files use a different extension (PFM? ATM? WTF? ;) )
 I guess you know what I meant here...

pdfFontSize ( font_handle, pointsize )
- sets the text size to "pointsize" points, e.g. "12" means 12-point ...for the font associated by font_handle

pdfFontWeight ( font_handle, style )
- sets the text style (any combination of "italic", "bold", "underlined" ) for the font associated by font_handle

pdfShow ( doc_handle, font_handle, textstring )
- outputs the text specified by "textstring" at the current cursor location on the current page of the doc_handle document
- updates (increments) the current writing position to after the end of the text just printed

pdfGetTextSize ( font_handle, textstring ) RETURNS sizepoints
- calculates the width in POINTS (measure of page) for the string specified by "textstring" if it would be printed using
 the font as specified by font_handle

pdfGetCurrPos ( doc_handle ) RETURNS pos_x, pos_y
- retrieves the x/y coordinates (in POINTS, measure of page) of the current writing position
 (e.g "0,0" = left/top corner)

pdfSetCurrPos ( doc_handle, pos_x, pos_y )
- sets the coordinates (in POINTS, measure of page) of the current writing position (offset for next output function)

pdfShowAt ( doc_handle, font_handle, textstring, pos_x, pos_y )
- for the lazy: combines pdfSetCurrPos() and pdfShow() into 1 function

pdfLoadPicture ( filename ) RETURNS pic_handle
- allocates a buffer to hold the file contained in the graphics file "filename" (fully-qualified; drive-path-filename-exstension)
- loads the picture from the graphics file specified by "filename" into memory buffer
- makes that buffer being accessible as "pic_handle"
- Note: Formats supported initially: BMP, PNG (no transparency support needed at first), JPG

pdfShowPicture (doc_handle, pic_handle, [size_x, size_y] )
- outputs the picture specified by pic_handle at the current writing position with no scaling/clipping/shrinking
- if size_x and size_y are specified, the picture is resized accordingly to these new dimensions before printing it

pdfLine ( doc_handle, pos_x1, pos_y1, pos_x2, pos_y2, thickness )
- draws a line from coordinate pos_x1/pos_y1 to coordinates pos_x2/pos_y2 using "thickness" points width
 (e.g.  12,100,100,150,3 -> draws a line of 3pt thickness from x=12,y=100 to x=100,y=150)

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
Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.07.22, 12:58:47
Hi,

and here's another interesting thing!
With the dawn of Apache FOP 1.0 I went to have a look what it actually is. And you know what? It's an XML-to-PDF engine.
(OK, it is more than that, but this is what is interesting within the context of this thread)

http://xmlgraphics.apache.org/fop/index.html

While this is a an almost perfect solution, I somehow have to admit the backdraws:
- it is Java (OK, who cares... it's only the "print engine", it requires JRE "1.4 or later")
- it uses XML and the REXX-support for creating XML is perhaps not in a good shape
  (still, we could "fake" XML syntax by creating falt text files with the according content)

This was just a teaser to trigger discussion around the topic... of course I still prefer a native, rexx-callable thing to create PDFs.
What do you think?

Cheers,
Thomas
Title: Re: RFC: A pretty-print processor?
Post by: RobertM on 2010.07.23, 00:16:45
Thomas,

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

Best,
Rob
Title: Re: RFC: A pretty-print processor?
Post by: 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
Title: Re: RFC: A pretty-print processor?
Post by: RobertM on 2010.07.25, 01:09:48
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 (http://www.igor.co.nz/rexxweb.htm), 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
Title: Re: RFC: A pretty-print processor?
Post by: RobertM on 2010.07.25, 01:51:58
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

Title: Re: RFC: A pretty-print processor?
Post by: jep on 2010.07.25, 17:46:02
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
Title: Re: RFC: A pretty-print processor?
Post by: RobertM on 2010.07.25, 19:18:37
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
Title: Re: RFC: A pretty-print processor?
Post by: jep on 2010.07.25, 23:14:34
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
Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.07.26, 12:27:11
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
Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.07.26, 12:32:44
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
Title: Re: RFC: A pretty-print processor?
Post by: Fr4nk on 2010.07.26, 17:13:59
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.

Title: Re: RFC: A pretty-print processor?
Post by: 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.
Title: Re: RFC: A pretty-print processor?
Post by: jep on 2010.07.27, 08:25:42
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
Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.07.27, 10:20:11
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
Title: Re: RFC: A pretty-print processor?
Post by: Fr4nk on 2010.07.27, 18:39:34
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.




Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.08.04, 16:16:38
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
Title: Re: RFC: A pretty-print processor?
Post by: jep on 2010.08.04, 17:02:38
Hello,

Quote from: warpcafe on 2010.08.04, 16:16:38
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?

A C-dll can be used by other programming languages as well as it doesn't add mangled function names or vendor specific magic like C++ can.

We can write it as a wrapper dll or build it into the dll itself next to the exported functions visible to the user.

//Jan-Erik
Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.08.26, 11:33:54
Hi,

okay let me ask:
Is there anyone here willing to give a try to make a rexx-callable DLL from the Haru sources?

Because if not, I would try to ask someone who I was told has done such things in the past. Alex Taylor. I don't know if he would be willing, able or simply whether he has the time to do it. I would even be willing to create another bounty for this by shifting my money from other "dead" bounties...

Cheers,
Thomas
Title: Re: RFC: A pretty-print processor?
Post by: jep on 2010.08.26, 20:26:47
Do ask him...

If someone else come up with the "plain" DLL, great, then I can write the REXX DLL stuff  :)

//Jan-Erik
Title: Re: RFC: A pretty-print processor?
Post by: warpcafe on 2010.08.27, 11:17:06
Hi Jep,

...well if it's about porting "only", I guess I should ask Paul Smedley first! :)

Will keep ypu updated, cheers,
Thomas