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
