Re: high resolution when printing to pdf, either from images or pdf widgets
On Sep 7, 2019, at 4:29 AM, Mark Waddingham via use-livecode wrote: > > On 2019-09-06 21:10, Dr. Hawkins via use-livecode wrote: >> On Aug 28, 2019, at 12:07 AM, Mark Waddingham via use-livecode >> wrote: >>> On 2019-08-27 17:24, Dr. Hawkins via use-livecode wrote: >>> I'm not entirely clear what Monte meant by 'print to pdf directly' in one >>> of those comments... The 'print to pdf' mechanism in the engine isn't >>> really any different from the normal printing mechanism, its just that >>> rather than funnel the sequence of paths, images, text being rendered >>> through the system printer it funnels it through libcairo's >>> (https://cairographics.org/) >>> PDF output functionality. >> Can this be adjusted for higher resolution? >> *is* there a way to send out at full resolution? > > I'm not sure I entirely follow - PDF is primarily a vector format so there is > 'resolution' as such. In regards to images then the engine/pdfprinter tries > to preserve the original image when printing - so if you print a large JPEG > scaled down to 100x100, the original JPEG will be passed into the PDF and then > that will be scaled down when rendered (i.e. as much information in the > original > is preserved in the output). ' Currently, the pdf gets 72’d when the engine renders. Could it simply be adjusted for, say, 300 dpi resolution on output? > >> I don’t need it to be the original, but rather visually indistinguishable. > > Then that changes things slightly - particularly if your originals are scans > which contain images rather than vectors... In this case, the render the PDF > at a larger size and scale down approach should be able to give you want you > want. My originals are almost if not entirely text, lines, and boxes. > >> As I think about it, I don’t think I’ve ever said *anything* nice >> about pdf. I’ve generally called it a bastardization >> of postscript, but in this case, “castration” might be a better word . >> . . (but then, when talking about cars, >> I refer to the period from the early 70s to the mid 90s as “the Great >> Emasculation” . . .) > > Heh - the main thing to remember about PDF is that it is designed to be a > description of what a postscript interpreter would output before things > get rasterized. The idea is that it is a flat sequence of things to render > and thus doesn't require the 'overhead' of a full programming language VM > to do so. Of course, whilst it is that, it has also become a rather > complicated > on-disk data structure. That’s not making me dislike it less :) >> My first attempt seemed to work, save for an approximately 25% size >> reduction I can’t explain. more below . . . >> I get a graphic of the same size as the pdf started, but the image is >> about 3/4 the original >> size. The rest is transparent area. >> My screen density is 108.79, but livecode doesn’t know that at the >> user code level, does it? >> However, that reduction *is* similar to 72/108.79 . . > > Physical screen density is irrelevant here - the engine uses a fixed > notion of 72dpi... The 3/4 reduction suggests something PDF side is actually > using 96dpi (72/96 = 3/4)... Perhaps Monte could chime in and comment? > > It might be you just have to adjust the zoom factor to scale up the PDF > slightly more so it fills the rect you want. I’m thinking that a variable density would be derivable here. Just increasing the zoom seem likely to do it, though: I start with a 612 wide pdf widget (8.5”), zoom it 400%, and get a graphic 4x612 wide. However, only the left and top 3/4 or so of the graphic is used, With the rest being blank. The right and bottom are transparent. On top of that, when I change the width back to 612, the resolution is apparently downscaled with it. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: high resolution when printing to pdf, either from images or pdf widgets
On 2019-09-06 21:10, Dr. Hawkins via use-livecode wrote: On Aug 28, 2019, at 12:07 AM, Mark Waddingham via use-livecode wrote: On 2019-08-27 17:24, Dr. Hawkins via use-livecode wrote: I'm not entirely clear what Monte meant by 'print to pdf directly' in one of those comments... The 'print to pdf' mechanism in the engine isn't really any different from the normal printing mechanism, its just that rather than funnel the sequence of paths, images, text being rendered through the system printer it funnels it through libcairo's (https://cairographics.org/) PDF output functionality. Can this be adjusted for higher resolution? *is* there a way to send out at full resolution? I'm not sure I entirely follow - PDF is primarily a vector format so there is 'resolution' as such. In regards to images then the engine/pdfprinter tries to preserve the original image when printing - so if you print a large JPEG scaled down to 100x100, the original JPEG will be passed into the PDF and then that will be scaled down when rendered (i.e. as much information in the original is preserved in the output). I don’t need it to be the original, but rather visually indistinguishable. Then that changes things slightly - particularly if your originals are scans which contain images rather than vectors... In this case, the render the PDF at a larger size and scale down approach should be able to give you want you want. As I think about it, I don’t think I’ve ever said *anything* nice about pdf. I’ve generally called it a bastardization of postscript, but in this case, “castration” might be a better word . . . (but then, when talking about cars, I refer to the period from the early 70s to the mid 90s as “the Great Emasculation” . . .) Heh - the main thing to remember about PDF is that it is designed to be a description of what a postscript interpreter would output before things get rasterized. The idea is that it is a flat sequence of things to render and thus doesn't require the 'overhead' of a full programming language VM to do so. Of course, whilst it is that, it has also become a rather complicated on-disk data structure. My first attempt seemed to work, save for an approximately 25% size reduction I can’t explain. more below . . . I get a graphic of the same size as the pdf started, but the image is about 3/4 the original size. The rest is transparent area. My screen density is 108.79, but livecode doesn’t know that at the user code level, does it? However, that reduction *is* similar to 72/108.79 . . Physical screen density is irrelevant here - the engine uses a fixed notion of 72dpi... The 3/4 reduction suggests something PDF side is actually using 96dpi (72/96 = 3/4)... Perhaps Monte could chime in and comment? It might be you just have to adjust the zoom factor to scale up the PDF slightly more so it fills the rect you want. Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: high resolution when printing to pdf, either from images or pdf widgets
On Aug 28, 2019, at 12:07 AM, Mark Waddingham via use-livecode wrote: > > On 2019-08-27 17:24, Dr. Hawkins via use-livecode wrote: >> I’ve seen references, even in the bug report, to “directly” printing >> to pdf from a widget. > > I'm not entirely clear what Monte meant by 'print to pdf directly' in one > of those comments... The 'print to pdf' mechanism in the engine isn't > really any different from the normal printing mechanism, its just that > rather than funnel the sequence of paths, images, text being rendered > through the system printer it funnels it through libcairo's > (https://cairographics.org/) > PDF output functionality. Can this be adjusted for higher resolution? > > If you want to augment an existing PDF with extra content then printing of > any form is not what you want. > *is* there a way to send out at full resolution? > Even when the various rather large and technical moving parts (pdfium, skia, > engine printing architecutre, engine pdf printer) involved in a non-rasterized > approach to printing pdf content displayed in stacks all align they would > still > not result in the original pdf being embedded verbatim in the output. I don’t need it to be the original, but rather visually indistinguishable. > > In reality your 'example' of embedding isn't really embedding - its manually > editing a single object's stream to be clipped - PDF's in general tend to be > a fair bit more complicated than that in the general case and indeed not what > most people would want and/or expect (immediate bug report if it did: I > printed > a small region of a 100Mb PDF to PDF and my output file was > 100Mb - > WHY?!?!). What I did was basically translate largely from postscript. With postscript, I could name the donor file’s commands, and then refuse sections of the donor (in some cases, repeatedly, possibly once, possibly dozens of times ). As I think about it, I don’t think I’ve ever said *anything* nice about pdf. I’ve generally called it a bastardization of postscript, but in this case, “castration” might be a better word . . . (but then, when talking about cars, I refer to the period from the early 70s to the mid 90s as “the Great Emasculation” . . .) > > >> In the meantime, though, has anyone actually managed to get hi-res >> output of either a pdf, jpg, or png into an outputted pdf? > > What you should find is that if you have a stack with an image object at size > 100x100 whose image (jpg or png) is actually 400x400, and then print it to pdf > then the full resolution of the image will be preserved. If this is not > happening > then chances are there is a property set somewhere which is requiring some > sort > of rasterization of the image object meaning the original image data cannot be > preserved (both PNG and JPEG image data passes straight through to the > printing > backend when possible). My first attempt seemed to work, save for an approximately 25% size reduction I can’t explain. more below . . . > >> The only way I’m seeing at the moment would be a bizarre process in >> which the stack is duplicated at 400%, and a script looping through to >> expand and replace every field, reposition and change the text size, >> etc., and then open the 33”x44” file in preview (or whatever) and >> export from there as 8.5”x1” . . . > > You shouldn't have to do that - all you should have to do is when printing > your > stack... > > 1) set the width and height of your PDF widget to Upscale * the original size > 2) import snapshot from pdf widget (make sure paintCompression is png) > 3) hide pdf widget > 4) set the width and height of the imported image to original size > 5) print > 6) delete image and show pdf widget given a full page 8.5x11” pdf named cd_pdf_wdg, I use the following: on mouseUp local oTl, oRect, nTl, nRect, tgPdf, tgPng, oSiz, nSiz local sDpi=72--108.79 set the paintCompression to "png" if there is a control "joe" then delete control "joe" put the long id of control "cd_pdf_wdg" into tgPdf put the rect of tgPdf into oRect put the height of tgPdf into oSiz put the width of tgPdf into item 2 of oSiz put the topLeft of tgPdf into oTl set the width of tgPdf to 4*8.5*sDpi set the height of tgPdf to 4*11*sDpi set the zoom of tgPdf to 400 set the topLeft of tgPdf to oTl import snapshot from tgPdf --import snapshot from rect the rect of tgPdf put the long id of it into tgPng set the name of tgPng to "joe" set the topLeft of tgPng to 0,0 set the rect of tgPdf to oRect set the zoom of tgPdf to 100 set the rect of tgPng to oRect end mouseUp I get a graphic of the same size as the pdf started, but the image is about 3/4 the original size. The rest is transparent area. My screen density is 108.79, but livecode doesn’t know that at the user code level, does it? However, that reduction *is* similar to 72/108.79 . . before resetting the rect of tgPng, it is indeed at screen resolution. It looks to be about a pixel by
Re: high resolution when printing to pdf, either from images or pdf widgets
> On 28 Aug 2019, at 5:07 pm, Mark Waddingham via use-livecode > wrote: > > I'm not entirely clear what Monte meant by 'print to pdf directly' in one > of those comments.. Ah I was talking about printing the PDF file directly. May have been before I realised there needed to be overlaid LC objects on the printout. Cheers Monte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: high resolution when printing to pdf, either from images or pdf widgets
On 2019-08-27 17:24, Dr. Hawkins via use-livecode wrote: I’ve seen references, even in the bug report, to “directly” printing to pdf from a widget. I'm not entirely clear what Monte meant by 'print to pdf directly' in one of those comments... The 'print to pdf' mechanism in the engine isn't really any different from the normal printing mechanism, its just that rather than funnel the sequence of paths, images, text being rendered through the system printer it funnels it through libcairo's (https://cairographics.org/) PDF output functionality. My experience has been that it still reduces the pdf to screen resolution. Currently widgets render at screen resolution when printed - this includes the PDF widget. I still insist they the fact that the engine *renders* the pdf, rather than including it, is a hard-core bug. I attached an example of including parts of a pdf into another. You can insist this but you'd be wrong :) If you want to augment an existing PDF with extra content then printing of any form is not what you want. Even when the various rather large and technical moving parts (pdfium, skia, engine printing architecutre, engine pdf printer) involved in a non-rasterized approach to printing pdf content displayed in stacks all align they would still not result in the original pdf being embedded verbatim in the output. In reality your 'example' of embedding isn't really embedding - its manually editing a single object's stream to be clipped - PDF's in general tend to be a fair bit more complicated than that in the general case and indeed not what most people would want and/or expect (immediate bug report if it did: I printed a small region of a 100Mb PDF to PDF and my output file was > 100Mb - WHY?!?!). [ I'd point out here that even CoreGraphics with its native/builtin support for PDF doesn't preserve original PDF content when you render a PDF into a PDF printing context - indeed it tends to lose various annotations/metadata which enable text to be copy/pasteable from the PDF ] In the meantime, though, has anyone actually managed to get hi-res output of either a pdf, jpg, or png into an outputted pdf? What you should find is that if you have a stack with an image object at size 100x100 whose image (jpg or png) is actually 400x400, and then print it to pdf then the full resolution of the image will be preserved. If this is not happening then chances are there is a property set somewhere which is requiring some sort of rasterization of the image object meaning the original image data cannot be preserved (both PNG and JPEG image data passes straight through to the printing backend when possible). The only way I’m seeing at the moment would be a bizarre process in which the stack is duplicated at 400%, and a script looping through to expand and replace every field, reposition and change the text size, etc., and then open the 33”x44” file in preview (or whatever) and export from there as 8.5”x1” . . . You shouldn't have to do that - all you should have to do is when printing your stack... 1) set the width and height of your PDF widget to Upscale * the original size 2) import snapshot from pdf widget (make sure paintCompression is png) 3) hide pdf widget 4) set the width and height of the imported image to original size 5) print 6) delete image and show pdf widget *IF* I could export to pdf at object density, I’d temporarily use png extracted from the pdf with an external program. You can - you just need to temporarily resize the pdf widget to upscale * size in points as suggested above and use import/export snapshot. And if I could fully figure out the pdf file structure, I could expand my example file to write a custom pdf merging the field output with other pdfs . . In reality if you want original PDF preserved with additions on top then that is your only option. Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
high resolution when printing to pdf, either from images or pdf widgets
I’ve seen references, even in the bug report, to “directly” printing to pdf from a widget. My experience has been that it still reduces the pdf to screen resolution. I still insist they the fact that the engine *renders* the pdf, rather than including it, is a hard-core bug. I attached an example of including parts of a pdf into another. In the meantime, though, has anyone actually managed to get hi-res output of either a pdf, jpg, or png into an outputted pdf? The only way I’m seeing at the moment would be a bizarre process in which the stack is duplicated at 400%, and a script looping through to expand and replace every field, reposition and change the text size, etc., and then open the 33”x44” file in preview (or whatever) and export from there as 8.5”x1” . . . This will yield crummy results, though, as livecode’s posting of text and use of margins in fields is nonlinear (to put it charitably!) *IF* I could export to pdf at object density, I’d temporarily use png extracted from the pdf with an external program. Another potential solution would be to export without the pdf and build a script to an external unix utility that could print a page of source pdf and my output to a third file. And if I could fully figure out the pdf file structure, I could expand my example file to write a custom pdf merging the field output with other pdfs . . — Richard E. Hawkins, Esq. The Hawkins Law Firm 3430 E. Flamingo Rd. Suite 232 Las Vegas, NV 89121 (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
