"Larry Serflaten" <serfla***@usinternet.com> wrote in message
news:endeS0c%23JHA.5780@TK2MSFTNGP03.phx.gbl...
>
> "John Simpson" <jas***@earthlink.net> wrote
>
>> Can anyone help me with this??
>>
>> '    Printer.Print ?????????     ' here's my problem
>>     Printer.EndDoc
>
> Try
>
> Printer.PaintPicture Pic1, 0, 0
>
> LFS
>
>

"Mike Williams" <M***@WhiskyAndCoke.com> wrote in message
news:%23jqmQXj%23JHA.5040@TK2MSFTNGP04.phx.gbl...
> "John Simpson" <jas***@earthlink.net> wrote in message
> news:uuKVpOc%23JHA.4360@TK2MSFTNGP04.phx.gbl...
>
>> OK, I'm stuck!
>> ' resize Pic1 code omitted for brevity
>> BeginPath Pic1.hdc
>> Pic1.CurrentX = 0
>> Pic1.CurrentY = 0
>> Pic1.Print TXT
>> EndPath Pic1.hdc
>> StrokePath Pic1.hdc
>> Printer.Print ?????????     ' here's my problem
>
> It is easily possible to print the picturebox contents to the printer,
> although the output quality would not be very good because you are
> effectively "stretching" a low resolution screen bitmap (96 dpi) so that
> it appears at a suitable size on a high resolution perhaps 600 dpi
> printer. The text outline on the printed page would therefore look fairly
> "blocky" on close inspection, partly because of the "pixel stretching" I
> mentioned and partly because the StrokePath API function does not use the
> text smoothing that standard characters use. So, the best way to draw the
> Path you have created to the Printer is to actually create it against the
> Printer.hdc and to use StrokePath Printer.hdc to print it, controlling the
> thickness of the outline with a Printer.DrawWidth statement if you want
> the outline to be greater than one printer pixel in thickness (which you
> in many cases would do because printer pixels are very small). However,
> because there are other issues with your existing PictureBox method in the
> code you have posted, and because some of those issues would also affect
> the "Stroke Path to Printer" method, I will deal here with the answer to
> the specific question you have asked (how to transfer the PictureBox drawn
> contents to the printer).
>
> The drawing created by your existing code ends up as a bitmap in the Image
> property of the PictureBox. You can print the Image property bitmap to the
> printer using Printer.PaintPicture pic1.Image but if you do it that way
> (without specifying a source size and without making any other
> modifications to your code) you may end up printing a bitmap that is
> larger than the current size of the PictureBox. That's because the bitmap
> contained in the Image property of a PictureBox still retains its previous
> pixel size even after you have resized the PictureBox unless the previous
> size was smaller than the "resized" size and the Image bitmap can
> therefore end up larger than the PictureBox that is displaying it, so if
> the PictureBox was originally larger than the size your code has resized
> it to then the bitmap in its Image property, and therefore the bitmap that
> gets printed, will be larger than you are expecting. You won't see the
> extra of course if the background is white, but you will if it is some
> other colour or if it contained a background of some kind. There are ways
> to overcome this problem using the various PaintPicture statement
> parameters but generally it is wise to resize the bitmap properly,
> especially if you ever wish to save the Image using SavePicture. There are
> all sorts of ways of forcing a PictureBox to reliably resize its bitmap
> Image and all of them are very simple. For example with your own code as
> posted you could simply move the Autoredraw statement to after the resize,
> or you could use a Cls method after the resize, there are all sorts of
> different ways. Personally in your own code I would suggest using Pic1.Cls
> immediately after the Pic1.Width and Pic1.Height statements. Then after
> you have finished your Picture Box drawing (after the StrokePath
> statement) use:
>
>    Printer.PaintPicture pic1.Image, 0, 0
>
> Having said all that, there are are few other things about your code that
> I would like to comment on. Firstly you are setting the Width and Height
> of the PictureBox to the desired size of the bitmap you intend it to
> contain. If the PictureBox has a border then the actual size of the bitmap
> it contains will be less than its overall width and height. So with a
> PictureBox that has a border you really need to be setting its Width and
> Height to a slightly greater value so that the size of the bitmap it
> contains is correct. This often (but not always) won't be a problem when
> the bitmap is just a string of text because in many cases there is some
> "white space" around the character cells anyway and so the characters
> themselves will probably still all be fully displayed, but it is wise not
> make that assumption and to size it properly. There are various ways of
> accounting for the border thicknesses to fix this problem but a simple
> "native VB code" method would be something like:
>
>    Dim xBorder As Single, yBorder As Single
>    pic1.ScaleMode = pic1.Container.ScaleMode
>    xBorder = pic1.Width - pic1.ScaleWidth
>    yBorder = pic1.Height - pic1.ScaleHeight
>    pic1.Width = pic1.TextWidth(TXT) + xBorder
>    pic1.Height = pic1.TextHeight(TXT) + yBorder
>
> As I've said, there are all sorts of different ways of doing the above but
> the important thing, whichever way you choose, is that you actually do it.
> The above code will reliably set the picbox overall size correctly so that
> its contained bitmap size (the client area) is the size you require but
> when dealing with the size of fonts there are also other things you need
> to take into consideration. That's because the VB TextWidth function and
> the alternative API GetTextExtentPoint32 function do NOT tell you the
> actual displayed width of the string of characters. They in fact tell you
> the width of the character cells in which the characters "live". This is
> often okay because many character glyphs in many fonts (the actual printed
> character shapes) live entirely within their cells, but in many cases it
> is not okay because some character glyphs overhang the border of their
> character cell at the left side or the right side or sometimes both sides.
> In fact in some cases some characters overhang the bottom of the character
> cell as well.
>
> To see what I mean first run your code as it currently exists (with or
> without the amendments I have mentioned) and you should see the word
> "TEMPLATE" entirely visible in the PictureBox. Now change the font to
> "Times New Roman" and add the line Pic1.Font.Italic = True and change the
> TXT variable from "TEMPLATE" to "fluff" and try it again. This time you
> should see that the text is not entirely visible, with the "f" characters
> in the word "fluff" overhanging the left side and the right side and the
> bottom edge of their cells. This is not a characteristic of the StrokePath
> function or of anything else in your code, but rather it is a
> characteristic of fonts in general and the same thing will happen if you
> use a standard Print statement or any other statement that prints text.
>
> As I've already mentioned, the problem arises because the TextWidth
> function (and the equivalent API GetTextExtent function) return the width
> of the string of text without taking into account any characters ate the
> left or right end of the string that might overhang their cells. Similarly
> the TextHeight function (and the equivalent API GetTextExtent function) do
> not take account of any characters that overhang the bottom of their
> cells. To calculate the correct size you need to get the width returned by
> the TextWidth (or the alternative GetTextExtent32) function and then add
> to that the amount by which the leftmost character overhangs the left edge
> of its cell and also the amount by which the rightmost character overhangs
> the right edge of its cell. Then when you have set the bitmap (the
> PictureBox client area or whatever) to the calculated width you need to
> position the x coordinate of the print statement to a positive value equal
> to the amount by which the leftmost character overhangs the left edge of
> its cell.
>
> If in any specific case you need to know only the left and right edge
> overhangs of a character then you can use the very simple GetCharABCWidths
> API function but if you want to also know the bottom edge overhang (not as
> common as left and right overhangs) then you'll need to use a something
> else, for example the slightly more complicated GetGlyphOutline API
> function which can get both the size and the position within the character
> cell of the "black box" (the black box is the smallest solid rectangle
> that would completely cover the actual character glyph).
>
> By the way, while on the subject of printing characters at a very large
> font size as you are doing you might also want to look at kerning, which
> is the amount of space that the designer of the font decided was the best
> between each specific pair of characters. When printing very large text,
> especially when it consists mainly of uppercase characters, it always
> looks best when it is properly kerned. For example, try the following:
>
>    Me.Font.Name = "Times New Roman"
>    Me.Font.Size = 100
>    Me.Print "AVERAGE"
>
> If you look at the output it appears as though the leading "A" is stuck
> out there on its own, with the "VERAGE" appearing to be a separate word.
> Also there is clearly too much white space between the second "A" and the
> "G". Positioning the characters in accordance with the spacing that the
> designer of the font decided upon makes it look much better. The optimal
> spacing between glyphs depends on the shape of the glyph and the glyph
> immediately following it and the spacing therefore needs to take into
> account both characters. The GetKerningPairs API function will tell you
> what spacing the font designer decided on for all specific pairs of
> characters in a specific font and size, and you can then use that
> information to space out your characters appropriately.
>
> This response is already quite long and in any case I'm not sure how far
> you want to take this stuff. Perhaps you might be happy to simply "add a
> bit extra" to account for the overhangs I have mentioned and perhaps you
> don't wish to bother with the added complication of kerning, but if you do
> want details of how to use the functions I have mentioned then post again.
>
> Mike
>
>
>

"John Simpson" <jas***@earthlink.net> wrote

> >> OK, I'm stuck!

> Mike,
>
> Thanks for taking the time to write a tutorial. It was very informative, and
> my senior citizen's brain could easily absorb it.
>
> As it turns out, I won't be able to go this route. I was going to print it  as a
> transparent 'overlay' on some Purchase Order forms that the client didn't want
> processed, but the white space in the picture box blocks some of the form.
> I'm just going to go with straight, big text. Not as cute, but it gets the point
> across. But I learned something today!