• 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

warpcafe

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:

  • a piece of software that takes a plain-text file as input
  • this file contains both formatting and contents
  • it processes these files and sends it to a printer
  • freeware of course
  • open-source perhaps (if someone else than me on this planet actually still uses VABasic for OS/2...)

To give you an example what would be feasible:

  • define page sizes and orientation
  • use and combine any available font on the system
  • free formatting (set cursor to x/y)
  • auto alignment (left/right/center) for a text string output
  • basic graphics function (draw lines, circles, rectangles...)
  • use bitmaps in print

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
"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

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


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


warpcafe

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
"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

#3
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



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


jep

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

Fr4nk

This sounds very interesting. Is there any progress in this project?


warpcafe

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
"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

#7
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.



jep

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

Fr4nk

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) ::)

warpcafe

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
"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

jep

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

Raiko

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 ...... ::)




warpcafe

#13
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
"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,

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
"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