Printing just one card to PDF [was Re: The owner of a selected control - a mystery]

[Terry Judd]

Hey Graham - I¹m pretty confident that you can get what you want with a
bit of fiddling. If your embedded images have large native dimensions
relative to their constrained LC dimensions then you should also be able
to support a bit of enlargement (of the PDF) as well without any visible
loss of image quality.

Terry...

On 23/02/2015 9:32 am, "Graham Samuel" <livfoss at mac.com> wrote:

>Thanks Jacque, and Terry too. I expect I¹ll hack it in the end by
>following your advice. I think now that I can use the print into rect
>version to actually enlarge the size of the card on the virtual paper,
>which will generate the hi-res result I want. I will try that.
>
>I just wanted a PDF representing the whole of a card with absolutely no
>additional white space or extra pages, and I wanted the highest
>resolution I could get. This is for illustrations in a manual that show
>the reader what he or she will see on the screen. Results up to now have
>been a bit fuzzy, which is where the hi-res idea comes from. Of course I
>don¹t expect bit-map images to look any sharper when they¹re enlarged,
>but everything else should.
>
>Graham
>
>
>> On 22 Feb 2015, at 21:08, J. Landman Gay <jacque at hyperactivesw.com>
>>wrote:
>> 
>> The printPaperSize reports the physical size of the sheet of paper. You
>>generally don't need to mess with that. Either restart LC to get rid of
>>the setting, or use resetPrinting from the message box to put everything
>>back to defaults. Remove that line of code. If your stack is smaller
>>than the size of the default PDF "paper," the handler was probably
>>making it too small to hold the content.
>> 
>> If the problem is the other way (the default paper size isn't large
>>enough) then setting the printPaperSize is okay because you need more
>>room. In that case what you've got should work if you add some extra
>>space for the printer driver limitations.
>> 
>> You're right about those, and you need to take those into account too.
>>Most printers can't print within a half inch of the top of the paper. If
>>you also have a top margin of, say, half an inch, then there's a full
>>inch at the top before the printing starts. Setting the topMargin to 0
>>will still cause the top of the printout to start at the half inch
>>required by the printer driver. If the content of your stack is not
>>located at the very top of the card, then add that amount to the top gap
>>as well.
>> 
>> I usually create a separate printing substack that moves data into
>>carefully placed fields that are located at the very edges of the card.
>>That makes it easier to calculate where the printout will start. I know
>>that setting the margins to, say, 18, will add a quarter inch to the
>>printer's required margins and that's where the content will begin to
>>print. If I use a printmargin of 0 it will put the content right up
>>against the default limit of the print driver.
>> 
>> Finally, if none of this works, then use the "print into rect" syntax.
>>LC will scale the printout to fit into the rectangle you specify.
>> 
>> On 2/22/2015 4:41 AM, Graham Samuel wrote:
>>> Not quite sure I understand this (I did once, but i¹ve got rusty - oil
>>>can!). I assumed that the following code would exactly fill a page:
>>> 
>>>    set the printCardBorders to true
>>>    set the printPaperSize to (the width of this card) & "," & (the
>>>height of this card)
>>>    set the printMargins to "0,0,0,0"
>>>    print this card
>>> 
>>> But maybe you're saying that there is some hidden factor here. One
>>>thing I can think of in a physical bit of paper (which a PDF isn't,
>>>really) is that only certain printers can print to the very edge, so
>>>there might be a kind of hidden margin (is this "the available print
>>>area"?). I am not sure if the printPaperRect comes into this: as far as
>>>I can see, it shouldn't, since the printMargins are measured from the
>>>edge of the page according to the LC Dictionary. The printing might be
>>>cropped if edge-to-edge isn't available, but that should not increase
>>>the number of pages printed, should it?
>>> 
>>> I will experiment some more.
>>> 
>>> Graham
>>> 
>>> 
>>>> On 21 Feb 2015, at 21:14, J. Landman Gay <jacque at hyperactivesw.com>
>>>>wrote:
>>>> 
>>>> On 2/21/2015 10:11 AM, Graham Samuel wrote:
>>>>> 1. When you print to a pdf file, you often get a blank page. I have
>>>>> not yet found that the solution offered (putting a Œprint break¹ into
>>>>> the script) works for me.
>>>> 
>>>> If the bounds of the printout overrun the available print area, LC
>>>>will push the content down to another page. It sounds like you may
>>>>have margins at either the top or bottom of the page that are too
>>>>large to accomodate the height of the printout.
>>>> 
>>>> You can set the margins to a smaller number, or use the "print into
>>>>rect" syntax to scale the output to fit. Remember when dealing with
>>>>margins that the margins represent the amount of space around the rect
>>>>of the card itself. If your fields or other controls are not at the
>>>>very edges of the card, then they will be inset more than just the
>>>>margin amounts.
>>>> 
>>>> --
>>>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>>>> HyperActive Software           |     http://www.hyperactivesw.com
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>>subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>> 
>> 
>> -- 
>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>> HyperActive Software           |     http://www.hyperactivesw.com
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>>subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>_______________________________________________
>use-livecode mailing list
>use-livecode at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode