| # | User | Message | Date |
| 156 | Graham | I've uploaded the 35 gnu ttf so that you can use postscript fonts for draw http://rebol.wik.is/Protocols/Printer | 29-Sep 22:52 |
| 155 | Graham | my code of course :( | 29-Sep 22:22 |
| 154 | Dockimbel | Is it an issue with View/Draw or a bug in your code ? | 29-Sep 22:15 |
| 153 | Graham | ie. not always working! | 29-Sep 22:09 |
| 152 | Graham | I have multipage preview working ... some time ... I have a block of draw blocks and I am supposed to switch between them to page thru the different pages. | 29-Sep 22:08 |
| 151 | Graham | that's an admirable aim ... just beyond my skill set | 29-Sep 22:07 |
| 150 | Dockimbel | Thanks for the food for thought, I think that I could reuse several routines from gonzo. But PS is just a low-level layer for my printer dialect, doing too sophisticated things at PS level is not an option for me. All the calculation and fancy things (like good justification) have to be done in Draw dialect, so that WYSIWYG can be achieved. | 29-Sep 22:06 |
| 149 | Graham | and apologies for the poor formatting .... | 29-Sep 22:05 |
| 148 | Graham | which you can strip out .. the preprocessing stuff. | 29-Sep 22:04 |
| 147 | Graham | Ok, sent ... it's got lots of stuff specific to my emr app | 29-Sep 22:04 |
| 146 | Graham | ie. I allow the template language to include an eps file | 29-Sep 21:51 |
| 145 | Graham | as no idea what it will look like | 29-Sep 21:50 |
| 144 | Graham | For eps, I just put a yellow box in the print preview .... | 29-Sep 21:49 |
| 143 | Dockimbel | ok, so it's 100% PS. I wrote a few helping functions in PS too. | 29-Sep 21:47 |
| 142 | Graham | has to be ... can't hide postscript source! | 29-Sep 21:45 |
| 141 | Graham | yes ... | 29-Sep 21:45 |
| 140 | Dockimbel | is gonzo open sourced ? | 29-Sep 21:45 |
| 139 | Graham | gonzo is a postscript utility to do micro justification and other goodies | 29-Sep 21:44 |
| 138 | Dockimbel | you should try to pipe the draw output to the printer scheme | 29-Sep 21:44 |
| 137 | Graham | but it handles rotations and translations poorly | 29-Sep 21:43 |
| 136 | Graham | yes. | 29-Sep 21:43 |
| 135 | Dockimbel | So, you have a draw converter for this dialect ? | 29-Sep 21:43 |
| 134 | Graham | the same dialect gets converted to draw to allow a preview. | 29-Sep 21:42 |
| 133 | Graham | yes, to make it easier to convert to postscript and to draw. | 29-Sep 21:42 |
| 132 | Graham | flowbox 75x150 540x590 float 20 means to put a text box that accepts text that flows into another box, but to start the text inside the box 20 points below any text above it. | 29-Sep 21:42 |
| 131 | Dockimbel | Looks like rebolized PostScript | 29-Sep 21:42 |
| 130 | Graham | This is the "dialect" I am using to generate a multi-page letter. Words like "consult-date" "provider" "My-name" are processed by a pre-processor to substitute the correct variables. | 29-Sep 21:41 |
| 129 | Graham | pagesize A4
font Times-BoldItalic 30
linewidth 1
at 190x750 My-Name
color (black)
font Times-Roman 12
newpath at 75x725 line1
at 75x715 line2
at 75x705 line3
at 445x715 "Ph: "
at 465x715 ph
at 445x705 "Fx: "
at 465x705 fx
at 438x680 "Date:" font Times-Bold at 465x680 consult-date
font Times-Roman 11
newpath at 75x740 line 530x740
newpath at 75x700 line 530x700
at 75x680 Provider-Template at 75x600 "Dear " at 100x600 Provider flow-translate 0x0 flowbox 75x150 540x590 float 20 flow-translate 0x0 flowbox 75x150 540x720 gonzo flow consult gonzo flow-translate 0x0 flowbox 75x150 540x720 float 10 flow-translate 0x0 flowbox 75x72 540x720 float 50 showpage | 29-Sep 21:39 |
| 128 | Dockimbel | I see, that's the kind of usage that I was thinking about too. | 29-Sep 21:39 |
| 127 | Dockimbel | The underlying GDI API I've used does a lot more than needed, I should restrict its behaviour. | 29-Sep 21:38 |
| 126 | Graham | My printing then uses the print template dialect to print page after page. | 29-Sep 21:37 |
| 125 | Graham | What I tried to do was create a print template that the user can define. | 29-Sep 21:37 |
| 124 | Graham | Sure .. | 29-Sep 21:37 |
| 123 | Dockimbel | Could you send me your Draw source code ? (privately or by email, if it's too long) | 29-Sep 21:36 |
| 122 | Graham | and if I run out of text boxes, it just keeps reusing the last text box ... for all subsequent pages | 29-Sep 21:36 |
| 121 | Graham | So, the text boxes are contained within the one page. | 29-Sep 21:34 |
| 120 | Graham | if the next text box is above the current text box, it assumes a page break and so starts a new page. | 29-Sep 21:34 |
| 119 | Graham | What I am doing now is printing the text to a virtual draw page, and then when it reaches the bottom of the text box, it then flows to the next text box. | 29-Sep 21:33 |
| 118 | Dockimbel | Text can only flow inside boxes fully contained inside a page. This is achieved by extending Draw dialect with a new primitive : 'text-box. | 29-Sep 21:32 |
| 117 | Dockimbel | Making text flow from one page to another is a job for a word-processor like MSWord or LaTeX. The printer scheme aims to be general purpose, so it can be used to print anything (not only output from word-processors). | 29-Sep 21:30 |
| 116 | Graham | So, how are you doing it ? multiple pages and text flow? | 29-Sep 21:29 |
| 115 | Dockimbel | Nope, that's too high-level, it's not a feature of Draw dialect. The printer scheme provides a cross-platform low-level layer to build such higher-level frameworks. | 29-Sep 21:25 |
| 114 | Graham | Does text flow from one page to another? | 29-Sep 21:23 |
| 113 | Dockimbel | 'end-page might be buggy in your version. | 29-Sep 21:23 |
| 112 | Dockimbel | you use commands like 'start-page/end-page to control paging and 'insert port [...draw dialect...] to draw content. | 29-Sep 21:22 |
| 111 | Graham | So, this implementation is as a page description language? | 29-Sep 21:19 |
| 110 | Dockimbel | and not use pair! for specifying X Y scaling values but decimal! values. | 29-Sep 21:19 |
| 109 | Dockimbel | It happens here too, I need to apply global scaling to text fonts too. | 29-Sep 21:17 |
| 108 | Graham | This is the same for all of the three lower text boxes | 29-Sep 20:58 |
| 107 | Graham | First issue .. the text box displays fine in the PDF, but when I print it write printer:// demo-doc the lower text box margin cuts into the bottom line of text so that only the top half of that line prints. | 29-Sep 20:58 |
| 106 | Graham | I've been pretty flat out as well, but will have a ook at it today. Thanks for the work. | 29-Sep 20:25 |
| 105 | Gregg | I hoped to have time Doc, but I don't have a need, and I seem to have *no* spare time for playing right now. :-( | 29-Sep 14:06 |
| 104 | Dockimbel | I'm about to release a new version of the printer lib with multiplatform support, so if anyone noticed something to fix or improve that I'm not aware of, that's the right time to report ;-). | 29-Sep 10:49 |
| 103 | Dockimbel | Did anyone experimented with the printer:// scheme on Windows ? Any feedback ? | 29-Sep 10:46 |
| 102 | Dockimbel | Thanks Henrik, I'll study your code too. | 17-Sep 6:16 |
| 101 | Henrik | called ean13.r.. although I don't remember if that specific one has PS support. | 16-Sep 22:56 |
| 100 | Henrik | I wrote a simple one that is available through rebol.org. | 16-Sep 22:51 |
| 99 | Dockimbel | Nice library, thanks for the link. | 16-Sep 22:01 |
| 98 | Graham | http://www.terryburton.co.uk/barcodewriter/ is the one I use .... | 16-Sep 21:59 |
| 97 | Dockimbel | (only EAN 13 support) | 16-Sep 21:56 |
| 96 | Dockimbel | Btw, I need to make a bar code generator for my current project, so that's something I'll work on soon. | 16-Sep 21:54 |
| 95 | Dockimbel | That shouldn't be hard to code in PS. Anyway, now I just need to code it in Draw, and let the printer:// scheme do the work. | 16-Sep 21:53 |
| 94 | Graham | there's also a very nice bar code generator for postscript. | 16-Sep 21:52 |
| 93 | Dockimbel | line wrap | 16-Sep 21:52 |
| 92 | Graham | word wrap or line wrap? | 16-Sep 21:51 |
| 91 | Dockimbel | I found a justification routine (doing also alignement). I need to study it to see if it fit my needs : align and line-wrap at the same time. | 16-Sep 21:50 |
| 90 | Graham | There are a few good justifications schemes available for postscript | 16-Sep 21:49 |
| 89 | Graham | don't bother with underline style! It's a relic of type setting. | 16-Sep 21:48 |
| 88 | Dockimbel | Scaling, auto-fit are also currently missing in the PS version. Landscape mode is also missing in both GDI and PS modes. | 16-Sep 21:48 |
| 87 | Dockimbel | To view the PS file, use ghostscript / gsview. | 16-Sep 21:47 |
| 86 | Dockimbel | Update on the work-in-progress : http://softinnov.org/tmp/test-page.zip Both files are printed from the same Draw dialect source, using my printer:// scheme. The PDF file is printed through Bullzip PDF Virtual printer. The PS file is directly generated by the printer scheme (for UNIX/Cups direct printing). Most of the PostScript support is done (see %test-page.ps), but there's still a lot of details to enhance/fix/add: o Add center/right alignement support o Add underline style for fonts o Fine-tune positionning and bold level. o Fix minor differences with the GDI version. | 16-Sep 21:45 |
| 85 | Henrik | the idea was to use size-text to produce the needed position, but the result is not usable, because I don't think DRAW uses the concept of a bounding box for text. | 13-Sep 17:54 |
| 84 | Henrik | no, I stopped spending time on it almost immediately after learning of this problem. | 13-Sep 17:50 |
| 83 | Dockimbel | Sure, if he has access to that part of the source code. Henrik, did you made a RAMBO ticket for that issue ? | 13-Sep 17:34 |
| 82 | Pekr | ... or ... we can ask Cyphre to fix it? :-) | 13-Sep 17:24 |
| 81 | Dockimbel | If Draw has really some issue with kerning, I can't see how we can fix that in R2. We'll have to live with an almost-WYSIWYG model. If R2 was open-sourced, that would be, of course, different. ;-) | 13-Sep 16:32 |
| 80 | Henrik | ok | 13-Sep 16:28 |
| 79 | Dockimbel | It's out of my scope currently, I didn't yet worked on the (cross-platform) preview window (where Draw engine will be used). | 13-Sep 16:28 |
| 78 | Henrik | yes | 13-Sep 16:26 |
| 77 | Dockimbel | R2 kerning issue with Draw that you were talking about ? | 13-Sep 16:23 |
| 76 | Henrik | did you solve the center/right adjustment problem? | 13-Sep 16:18 |
| 75 | Dockimbel | (oops sorry, wrong window, please ignore my last post) | 13-Sep 16:08 |
| 74 | Dockimbel | le blog de Billaut : http://billaut.typepad.com/ | 13-Sep 16:07 |
| 73 | Dockimbel | ;-) | 13-Sep 16:01 |
| 72 | Henrik | now it's getting really interesting :-) | 13-Sep 15:59 |
| 71 | Dockimbel | I know that Geomol has built a PS lib but, unfortunately, it doesn't take Draw dialect as input. | 13-Sep 15:48 |
| 70 | Dockimbel | For information, I've successfully tested direct printing in Linux and OS X using PostScript format documents and CUPS as backend. I'm currently trying to implement a Draw dialect compiler targeting PS. Unix and OS X support wasn't needed for my project, but I couldn't resist to give it a try ;-). | 13-Sep 15:46 |
| 69 | Louis | http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=crystal-reports.r | 9-Sep 23:05 |
| 68 | Gregg | "who wants to clone Crystal Reports ?" We would need a /bloat refinement to do that. :-) | 9-Sep 19:47 |
| 67 | Henrik | mine focuses more on the UI side, offering various methods of printing postscript. there is also a printer queue system as well as a printer server. | 9-Sep 12:24 |
| 66 | Henrik | I wish I could integrate this with my own printing system, but it's highly postscript oriented. | 9-Sep 12:23 |
| 65 | Dockimbel | I've looked at the cross-platform aspects of printing. I think that it could be possible to add support for PS and PDF generators for Unix and OSX printing support. So we could have the same dialect to draw on screen and on printers (on all majors platforms). | 9-Sep 11:32 |
| 64 | Pavel | But this is the merit, everybody could do it (OK almost everybody, not me for example), but you did it. Printing points up dual problem, first it is definitely against Cross-platformity, but second if anybody intents to work seriously (make real aplications) definitely need it. | 9-Sep 10:11 |
| 63 | Dockimbel | Thanks but this isn't really such a great piece of code (Windows API is doing the real job), even if it fills a gap in REBOL (at least for Windows). Btw, in my company, we're using Gab's pdf-maker for years now to generate and print all our documents. I made this library only because I needed a direct printing solution for a customer and I must admit it was a fun work to do. | 9-Sep 9:31 |
| 62 | Pavel | It must be said clearly YOU ARE THE GREAT! thx for this all | 9-Sep 9:16 |
| 61 | Dockimbel | Btw, it's possible to list the available printers using : probe printer/enum | 9-Sep 9:15 |
| 60 | Dockimbel | Not currently, but it could be added. | 9-Sep 9:12 |
| 59 | Henrik | I'm unable to test it here, but what about bringing up the printer dialog? Does that happen? | 9-Sep 7:11 |
| 58 | Dockimbel | Gregg: I must admit that I missed the good old VB printer object. So now, who wants to clone Crystal Reports ? ;-) | 9-Sep 5:50 |
| 57 | Graham | Fantastic! | 9-Sep 4:08 |
| 56 | Gregg | Awesome Doc! I thought I had forever gotten away from start-doc/end-doc, but I guess old APIs never die. :-) | 8-Sep 23:39 |
| 55 | Dockimbel | Last but not least, the usual one-liner : write printer:// [text 10x10 "Hello World!"] ;-) | 8-Sep 18:20 |
| 54 | Dockimbel | I don't think that I will have time to add all those features, so it's left as an exercice for the community ;-). | 8-Sep 18:16 |
| 53 | Dockimbel | Possible additionnal features : - Support for preview View window is possible, but requires some fine tuning first in Printer scheme, for WYSIWYG support. - Support for Windows standard printer dialog window could be added. - Support for setting page orientation, page copies, etc...could be added. | 8-Sep 18:15 |
| 52 | Dockimbel | Btw, the printer dialect use milimeters as unit for positioning and size. | 8-Sep 18:10 |
| 51 | Dockimbel | p: open printer://
insert p 'start-doc insert p 'start-page insert p [text "Page 1" 50x50] insert p 'end-page insert p 'start-page insert p [text "Page 2" 50x50] insert p 'end-page ... insert p 'end-doc ;-- this one triggers the real printing close p | 8-Sep 18:08 |
| 50 | Dockimbel | Example of multiples pages printing : | 8-Sep 18:08 |
| 49 | Dockimbel | I highly recommand the excellent Bullzip free PDF Printer for testing : http://www.bullzip.com/download/pdf/BullzipPDFPrinter_5_0_0_609.zip | 8-Sep 18:05 |
| 48 | Dockimbel | But Draw dialect is really too level for a daily use. A higher level dialect with relative positionning and higher level constructs (e.g. tables support), like VID or HTML is needed. | 8-Sep 18:02 |
| 47 | Dockimbel | Draw dialect maps very well with Windows drawing API (GDI). It's, in most cases, a one to one mapping. | 8-Sep 17:59 |
| 46 | Dockimbel | There's still some glitches and it needs some fine-tuning before providing real WYSIWYG results when compared to Draw rendering. | 8-Sep 17:57 |
| 45 | Dockimbel | No docs for now, look at the sample %test-page.r script and at the scheme implementation. Input dialect is a subset of Draw dialect. | 8-Sep 17:55 |
| 44 | Dockimbel | First test release of Printer scheme for direct printing on Windows platforms : http://softinnov.org/tmp/printer.zip | 8-Sep 17:54 |
| 43 | Kaj | I'm very interested in this for both REBOL and Syllable | 7-Sep 20:29 |
| 42 | Kaj | So would or wouldn't you advise to go through PDF for printing to GhostScript? | 7-Sep 20:28 |
| 41 | BrianH | It wouldn't be the wrapping of the Windows API that would help Linux users, it would be his initial work on making a Draw-like printing dialect. Defining the dialect is a large part of the process of supporting printing in REBOL. There will be non-Windows-specific parts of Doc's implementation that can be adapted to a general printing model for REBOL, one that can have multiple implementations with different backends. For that matter, there would need to be at least 3 backends: GDI (for Windows), Postscript (for Ghostscript) and PDF (for Mac Quartz), with a possible XPS backend as a minor variation on the PDF one. | 4-Sep 23:44 |
| 40 | Graham | So, we need to continue supporting postscript. | 4-Sep 23:21 |
| 39 | Graham | Wrapping the windows printing api doesn't help linux users :) | 4-Sep 23:21 |
| 38 | BrianH | Well, if you are using the OS's facilities for printing you are using the API version of the semantics, not necessarily the source. What really matters is the semantics - the source is just a generated representation. | 4-Sep 21:40 |
| 37 | Henrik | or perhaps more appropriate, what OpenGL does for displaying 3D graphics on screen. | 4-Sep 21:32 |
| 36 | Henrik | I guess what I would want for printers, would be like what HTML does for webbrowsers. | 4-Sep 21:30 |
| 35 | Henrik | but they are not source compatible, are they? | 4-Sep 21:30 |
| 34 | BrianH | But they did converge with existing systems, in semantic model. XPS is not that far off of PDF in semantics. | 4-Sep 21:29 |
| 33 | Henrik | And I think it sucks that Microsoft choose to invent yet another printer driver mess, rather than converge with existing systems. | 4-Sep 21:27 |
| 32 | Henrik | Well, I still think postscript should have become more widespread than it ended up being. And you can't change my opinion on that. :-) I crave standardization. OK, so if postscript was too hardware hungry, then a lighter version could have helped, which is why I wonder why PDF came so late. | 4-Sep 21:26 |
| 31 | BrianH | Remember that the procedural model of Postscript meant that a Postscript printer was a computer, and definitely a more powerful and more expensive computer than most people could afford. Even faking Postscript support required a computer of at least the same scale. | 4-Sep 21:22 |
| 30 | BrianH | Postscript printers had much more RAM than that, even then. | 4-Sep 21:19 |
| 29 | BrianH | Windows 1 ran in 512k or less of RAM, as I recall (likely badly). | 4-Sep 21:18 |
| 28 | BrianH | You know, when they added 80286 support. | 4-Sep 21:17 |
| 27 | BrianH | Initial versions of GDI predate Windows 2. | 4-Sep 21:17 |
| 26 | BrianH | That was considered a hard problem on 8086 computers. Remember how far back the "beginning" was... | 4-Sep 21:16 |
| 25 | Henrik | no, they would have made postscript rasterizers to make postscript work properly on cheap printers. | 4-Sep 21:13 |
| 24 | BrianH | At the start, postscript printers cost thousands of dollars but dot matrix printers cost a couple hundred. If MS had gone with Postscript, printing would have been stillborn outside of large companies. | 4-Sep 21:12 |
| 23 | Henrik | It might have had problems, but it would have been a much better starting point, had Microsoft embraced postscript from the start. There would have been a common starting point and a much larger incentive for building hardware postscript printers at the time. If that had been done, printer drivers would not be necessary under any platform today, or they would be limited to being postscript rasterizers. | 4-Sep 21:10 |
| 22 | BrianH | It would probably be easier to get AGG to output stuff in a form GDI would like though, with more overhead from pushing around all of that bitmap data of course. | 4-Sep 21:08 |
| 21 | BrianH | XPS is like a cleaned-up, extended PDF, with an XML representation if you're into that. The models are similar. | 4-Sep 21:06 |
| 20 | BrianH | That's why Apple based its Quartz model on PDF, when they already had a Postscript model from NeXT. | 4-Sep 21:02 |
| 19 | BrianH | That doesn't even include the execution model change from programmatic (Postscript) to declarative (PDF). | 4-Sep 21:00 |
| 18 | BrianH | Read up on the research on PDF sometime before you start promoting Postscript. It is even a good idea to use PDF instead if you are outputting through Ghostscript - it can handle it. | 4-Sep 20:58 |
| 17 | BrianH | No, it would have been horrible. There is a reason that even Adobe has moved away from Postscript - its model has major problems. | 4-Sep 20:57 |
| 16 | Dockimbel | Here's a nice introduction to XPS : http://msdn.microsoft.com/en-us/library/ms742418.aspx | 4-Sep 20:56 |
| 15 | Henrik | it would have been a lot more fun if they just used postscript :-) | 4-Sep 20:56 |
| 14 | BrianH | From what I can tell, they did a lot of interesting research when they came up with XPS - food for thought. | 4-Sep 20:55 |
| 13 | BrianH | It might make more sense for R3, mostly as a thought experiment to help us decide on the semantics of the REBOL printing model. | 4-Sep 20:54 |
| 12 | Dockimbel | Righ, gobs being lower level would require less work to map to OS Printing API. | 4-Sep 20:54 |
| 11 | Dockimbel | I had a quick look at XPS API, but it looked more complicated and required more work than GDI API. There was also the compatibility issue, I needed a solution that would work with any printer. I'll gave a deeper look at XPS latter. | 4-Sep 20:53 |
| 10 | Henrik | DocKimbel, you'll find that R2 Draw has kerning problems. Or at least that's what it had the last time I looked. That makes it difficult to center and right align text. This is not an issue in R3. | 4-Sep 20:50 |
| 9 | BrianH | The Gob model is much better-suited to adaptation to printing, IMO. | 4-Sep 20:49 |
| 8 | BrianH | For R3 you might look into the rich text support. I am less familiar with R2's Draw (and that's saying a lot). | 4-Sep 20:49 |
| 7 | Dockimbel | I also need to add extend Draw dialect with a new command: text-box. It's an improved version of 'text that allow you to define a bouding box, align the text horizontally and vertically and auto-wrap text. | 4-Sep 20:47 |
| 6 | BrianH | Have you considered the XPS printing API? I gather the semantic model is much better. | 4-Sep 20:47 |
| 5 | Dockimbel | Quite well so far. I currently only supports the following Draw commands : text, line, box, font, pen | 4-Sep 20:45 |
| 4 | BrianH | How well does the Draw semantic model map to the Windows printing semantic model? | 4-Sep 20:42 |
| 3 | Dockimbel | My library is just a thin layer that maps Draw dialect to Win32 Printing API. | 4-Sep 20:41 |
| 2 | Dockimbel | I've just built a direct printing library for R2, Windows only. It's a wrapper on Win32 Print API, so it supports all printers. It support a subset of Draw dialect as input. I was needing it to print reports for the project I'm currently working on. It still needs some additionnal work to be released publicly (like adding a port scheme layer for more intuitive usage). | 4-Sep 20:40 |
| 1 | Dockimbel | This group is about Printing solutions for REBOL. | 4-Sep 20:39 |