On Sep 7, 2019, at 4:29 AM, Mark Waddingham via use-livecode <use-livecode@lists.runrev.com> 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 >> <use-livecode@lists.runrev.com> 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
