Fonts, wonderful fonts. 
Author Message
 Fonts, wonderful fonts.

Based on extensive google searching (is that even possible?) I've come to the conclusion that a problem I've encountered is not solvable using the general direction of attack I've been attempting.

In a nutshell, I'm trying to send Payroll Direct Deposit Statements to employees from our accounting package.  The actual sending via e-mail is not the problem.  The printing of the statements (on paper) is not a problem.  What has me losing what's left of my hair is getting the paper statements into a format suitable for transfer via e-mail.

What made perfect sense to me was using the exact same routines that send the information to the printer object, and simply redirecting output to a picturebox.  Simple, right?

Not if you are using an eight-point font, it's not.

After delving deeper into my own code than I wanted to, I discovered that when you set a printer's font size to eight, it's eight.  When you set a picturebox's font size to eight, it's 8.25.  Doesn't seem to matter which font you use, and my googling has explained why the screen seems unable to do an 8-point font, so if I want my statements to look "professional" how do I get this beautiful work of art that I create from paper to a format that I can e-mail without having to completely duplicate (well, almost duplicate) all the code used to print the statements?

Even if I didn't have the font problem, the picturebox only seems to be able to export to .BMP file format, which makes the file 2 megabytes in size.  I realize that if I got that far, I could shrink that down a bit by reducing the size of the picturebox from a whole page to 2/3 page, which is all a statement uses anyway.

Since the statement does use different font sizes and styles, I'd like it to be more than just a text message.

Has anyone figured out a way for a print previewer to exactly match a paper copy, or do I need to regroup and attack this with some completely other martial art?

Bill "the nearly bald" Hileman



Sat, 18 Feb 2012 02:22:34 GMT  
 Fonts, wonderful fonts.


Based on extensive google searching (is that even possible?) I've come to
the conclusion that a problem I've encountered is not solvable using the
general direction of attack I've been attempting.

In a nutshell, I'm trying to send Payroll Direct Deposit Statements to
employees from our accounting package.  The actual sending via e-mail is not
the problem.  The printing of the statements (on paper) is not a problem.
What has me losing what's left of my hair is getting the paper statements
into a format suitable for transfer via e-mail.

What made perfect sense to me was using the exact same routines that send
the information to the printer object, and simply redirecting output to a
picturebox.  Simple, right?

Not if you are using an eight-point font, it's not.

After delving deeper into my own code than I wanted to, I discovered that
when you set a printer's font size to eight, it's eight.  When you set a
picturebox's font size to eight, it's 8.25.  Doesn't seem to matter which
font you use, and my googling has explained why the screen seems unable to
do an 8-point font, so if I want my statements to look "professional" how do
I get this beautiful work of art that I create from paper to a format that I
can e-mail without having to completely duplicate (well, almost duplicate)
all the code used to print the statements?

Even if I didn't have the font problem, the picturebox only seems to be able
to export to .BMP file format, which makes the file 2 megabytes in size.  I
realize that if I got that far, I could shrink that down a bit by reducing
the size of the picturebox from a whole page to 2/3 page, which is all a
statement uses anyway.

Since the statement does use different font sizes and styles, I'd like it to
be more than just a text message.

Has anyone figured out a way for a print previewer to exactly match a paper
copy, or do I need to regroup and attack this with some completely other
martial art?

Bill "the nearly bald" Hileman

------------------------------------------

Personally, if I HAD to do this, I'd create either a RichText or HTML email
rather than mess around with a PictureBox.  However, in either case, the
recipient(s) could choose to only display email using plain text, making all
that work to have a nice, pretty, formatted email completely worthless.  So,
simply creating a plain text email is probably the "safest" and easiest
option. Afterall, the whole point is to just let the employee know his/her
paycheck has been deposited, right? And the employees DO get a paycheck stub
via regular mail or handed out during work or however, right? So the email
is really just a duplicate statement that the employee might receive sooner,
right?  Sending an email out is just not something I'd spend a lot of time
working on. And besides that, an employee can probably go online at his/her
own bank to verify it (the email really doesn't *prove* it was desposited
anyway).

What accounting package do you use? I ask because I wrote something to do a
similar thing for Microsoft Dynamics GP. It wasn't for payroll direct
deposit, but EFTs to vendors. Because there's no paycheck stub or other
statement, many of our clients desire an email be sent to their vendors when
an EFT payment has been made.

However, another option you might consider would be to create a file (Word
document, .rtf, .html, .pdf, etc.) and attach that to the email. But again,
that could be iffy too because you probably can't be sure the attachment
won't be blocked.

--
Mike

P.S.  Anybody know what the deal is when OE (or Windows Mail in Vista)
doesn't quote the original post? I always thought it was only when the
original was HTML, but Bill's post was not HTML.  It was plain text and
still Windows Mail didn't quote it. Is it a setting I have wrong, or
something else in the original?



Sat, 18 Feb 2012 03:44:59 GMT  
 Fonts, wonderful fonts.

Quote:



> Based on extensive google searching (is that even possible?) I've
> come to the conclusion that a problem I've encountered is not
> solvable using the general direction of attack I've been attempting.

> In a nutshell, I'm trying to send Payroll Direct Deposit Statements to
> employees from our accounting package.  The actual sending via e-mail
> is not the problem.  The printing of the statements (on paper) is not
> a problem. What has me losing what's left of my hair is getting the
> paper statements into a format suitable for transfer via e-mail.

> What made perfect sense to me was using the exact same routines that
> send the information to the printer object, and simply redirecting
> output to a picturebox.  Simple, right?

> Not if you are using an eight-point font, it's not.

> After delving deeper into my own code than I wanted to, I discovered
> that when you set a printer's font size to eight, it's eight.  When
> you set a picturebox's font size to eight, it's 8.25.  Doesn't seem
> to matter which font you use, and my googling has explained why the
> screen seems unable to do an 8-point font, so if I want my statements
> to look "professional" how do I get this beautiful work of art that I
> create from paper to a format that I can e-mail without having to
> completely duplicate (well, almost duplicate) all the code used to
> print the statements?

> Even if I didn't have the font problem, the picturebox only seems to
> be able to export to .BMP file format, which makes the file 2
> megabytes in size.  I realize that if I got that far, I could shrink
> that down a bit by reducing the size of the picturebox from a whole
> page to 2/3 page, which is all a statement uses anyway.

> Since the statement does use different font sizes and styles, I'd
> like it to be more than just a text message.

> Has anyone figured out a way for a print previewer to exactly match a
> paper copy, or do I need to regroup and attack this with some
> completely other martial art?

> Bill "the nearly bald" Hileman

> ------------------------------------------

> Personally, if I HAD to do this, I'd create either a RichText or HTML
> email rather than mess around with a PictureBox.  However, in either
> case, the recipient(s) could choose to only display email using plain
> text, making all that work to have a nice, pretty, formatted email
> completely worthless.  So, simply creating a plain text email is
> probably the "safest" and easiest option. Afterall, the whole point
> is to just let the employee know his/her paycheck has been deposited,
> right? And the employees DO get a paycheck stub via regular mail or
> handed out during work or however, right? So the email is really just
> a duplicate statement that the employee might receive sooner, right?
> Sending an email out is just not something I'd spend a lot of time
> working on. And besides that, an employee can probably go online at
> his/her own bank to verify it (the email really doesn't *prove* it
> was desposited anyway).

I think that's what I'm going to end up doing - just send a plain text e-mail notifying the employee that his deposit has been done.  

Quote:

> What accounting package do you use? I ask because I wrote something
> to do a similar thing for Microsoft Dynamics GP. It wasn't for
> payroll direct deposit, but EFTs to vendors. Because there's no
> paycheck stub or other statement, many of our clients desire an email
> be sent to their vendors when an EFT payment has been made.

This is our own accounting package.  We have some holdover users still using our DOS package, and you know how sales/marketing can drive development.  A user wants this before they'll upgrade.  We had direct deposit in our DOS version, too, they just want this one additional item before they upgrade.

Quote:
> However, another option you might consider would be to create a file
> (Word document, .rtf, .html, .pdf, etc.) and attach that to the
> email. But again, that could be iffy too because you probably can't
> be sure the attachment won't be blocked.

My original concept was to attach it anyway - a graphics image of the statement.  What I was trying to avoid was having to completely re-code the logic that already works quite well with a physical printer, but it would appear that it won't be possible, or at least not the best solution.  I'm thinking they want to save time, paper, and stamps of mailing statements, since e-mail is effectively free, so this solution might not be what they want.  We'll see.


Sat, 18 Feb 2012 04:38:24 GMT  
 Fonts, wonderful fonts.

Quote:
> I'm trying to send Payroll Direct Deposit Statements to employees
> from our accounting package . . . The printing of the statements
> (on paper) is not a problem.  What has me losing what's left of my
> hair is getting the paper statements into a format suitable for transfer
> via e-mail . . . I discovered that when you set a printer's font size to
> eight, it's eight . . . and When you set a picturebox's font size to
> eight, it's 8.25.

Actually it's not quite that simple either! In a nutshell, you can normally
only get a font size that happens to be a whole pixel value on the device
you are using. If you are getting 8 points exactly on your printer then you
are probably using a 360 or 720 dpi printer (possibly an Epson, although
there are many others). That's because there are always 72 points per inch
and 8 points on a 720 dpi printer is therefore 8/72 * 720 = 80 pixels.
However on a 600 dpi printer (such as a typical HP printer) 8 points is 8/72
* 600 = 66.667 pixels, which is not a whole pixel value. The nearest you can
get on a HP printer is therefore 8.04 points, which is exactly 67 pixels on
that printer. On a computer screen (tpyically running at 96 dpi) 8 points
would be 8/72 * 96 = 10.67 pixels. The nearest whole pixel value to that is
11 pixels, which equates on such a machine to 8.25 points. In other words,
you can get a value that is equal to, or at least very close to, your
desired font size on most printers because of their high dpi resolution,
whereas on the display, which has a relatively low resolution, you often
cannot get anywhere near as close to your desired value. There is even more
to it that that, because as well as the point size (which of course is a
vertical measurement) the "whole pixel" limitation also applies to the cell
width of each individual character in any string you print, which means the
horizontal width of a piece of text can be different on different devices
even when you actually can achieve exactly the same font size on both of
them! For example 9 points is exactly available on all three devices I have
mentioned (96 dpi, 600 dpi and 720 dpi) but the logical width of a string of
text on each of those devices can be different, even though they are all
using a 9 point font. There is a lot more that can be said about this of
course, but that's the basics of it.

Quote:
> Even if I didn't have the font problem, the picturebox only
> seems to be able to export to .BMP file format, which
> makes the file 2 megabytes in size.

You could add some code to convert the bitmap to a jpeg (there are various
DLLs available that can help you to do that) but actually if you want a
quality output then you are better off avoiding bitmaps (and jpegs) anyway.

Quote:
> so if I want my statements to look "professional" how do
> I get this beautiful work of art that I create from paper to
> a format that I can e-mail without having to completely
> duplicate (well, almost duplicate) all the code used to
> print the statements?

There are two approaches I can think of. The first is to create your Deposit
Statement as a Windows metafile (.wmf, or preferably .emf). You can continue
to print your own output to the VB Printer Object as you are currently
doing, or you can instead send the completed metafile to your printer using
the VB PaintPicture method (the latter is the better option because you will
be guaranteed that the layout, word wrap points, etc, etc are exactly the
same on your own printout as they would be when your customer prints the
metafile you send him). Metafiles are vector based and so you will get
essentially exactly the same high quality printed output as you are getting
now. You can then email the metafile as a standard .emf file to your
customer and he can view it directly in his email reader or print it or
display it from any application he has that is capable of doing so (all
sorts of different applications). The problem with this approach is that VB
native Printer Object methods cannot be directed to metafiles, and so you
would need to use the equivalent API (GDI) functions instead, for example
using the GDI TextOut method instead of the VB Print method, etc. This would
cause you quite a bit of work, but it would be worth it in the end.

The second approach is to continue to print your own copy as you are
currently doing (using the VB Printer Object and its various methods) but to
send them to your own printer when you want a hard copy of your own and to
send them instead to a PDF "virtual printer" when you want to produce a pdf
file. As I'm sure you are aware, PDF files are industry standard document
files and they can be viewed by anyone who already has or is prepared to
download a PDF viewer. PDF printers really are very useful things. They are
not real printers of course (just software "pretend printers") but they
install themselves as standard Windows printers and they behave as standard
Windows printers. The PDF file format is in one major way similar to the
metafile format, at least as far as it is a vector based format, and so it
produces just as high quality output. Also, you can use exactly the same VB
printing code on a PDF printer as you use on a real printer, so you will not
need to amend your current VB printing code at all. There are a number of
freeware PDF printers around. PrimoPDF is a good one, but (as far as I can
see) it always pops up a user file and settings dialog, which is a
limitation in terms of automation. Another good one, which has the advantage
that it can be set to produce a named .pdf file in a specific folder without
any user interaction, is PDFCreator. So using PDFCreator your VB code can
use standard VB Printer Object methods (directed to the PDFCreator
"printer") to create your document as a named .pdf file. Your code can then
load up that file and email it to your customer. You can download PDFCreator
at:

    http://sourceforge.net/projects/pdfcreator/

I've just got back from holiday and I haven't really "got my head on" yet
and there is a lot more that I can say about this stuff, but the above
should at least get you going.

Mike



Sat, 18 Feb 2012 04:43:48 GMT  
 Fonts, wonderful fonts.


Quote:

> P.S.  Anybody know what the deal is when OE (or Windows Mail in Vista)
> doesn't quote the original post? I always thought it was only when the
> original was HTML, but Bill's post was not HTML.  It was plain text and
> still Windows Mail didn't quote it. Is it a setting I have wrong, or
> something else in the original?

I've heard different explanations dealing mostly with posters from certain
readers (like Google Groups). And solutions from ignoring such ppl to
getting a better news reader.

When I remember to invoke it I like this little utility ...
OE-QuoteFix
http://home.in.tum.de/~jain/software/oe-quotefix/

-ralph



Sat, 18 Feb 2012 04:40:28 GMT  
 Fonts, wonderful fonts.
I have not done what you are trying to do but the other day I ran into
a program called PDFCreator which becomes a virtual printer that
outputs PDF files.
You could really get fancy if you wanted as PDF files support all
fonts shapes & sizes, color, pictures of all kinds etc. I think it is
certainly worth looking at and could provide you with a very robust
solution.

The link to download PDFCreator is:

http://sourceforge.net/projects/pdfcreator/

Good Luck

Duke


Quote:
> Based on extensive google searching (is that even possible?) I've come to the conclusion that a problem I've encountered is not solvable using the general direction of attack I've been attempting.

> In a nutshell, I'm trying to send Payroll Direct Deposit Statements to employees from our accounting package. ?The actual sending via e-mail is not the problem. ?The printing of the statements (on paper) is not a problem. ?What has me losing what's left of my hair is getting the paper statements into a format suitable for transfer via e-mail.

> What made perfect sense to me was using the exact same routines that send the information to the printer object, and simply redirecting output to a picturebox. ?Simple, right?

> Not if you are using an eight-point font, it's not.

> After delving deeper into my own code than I wanted to, I discovered that when you set a printer's font size to eight, it's eight. ?When you set a picturebox's

font size to eight, it's 8.25. ?Doesn't seem to matter which font you
use, and my googling has explained why the screen seems unable to do
an 8-point font, so if I want my statements to look "professional" how
do I get this beautiful work of art that I create from paper to a
format that I can e-mail without having to completely duplicate (well,
almost duplicate) all the code used to print the statements?
Quote:

> Even if I didn't have the font problem, the picturebox only seems to be able to export to .BMP file format, which makes the file 2 megabytes in size. ?I realize that if I got that far, I could shrink that down a bit by reducing the size of the picturebox from a whole page to 2/3 page, which is all a statement uses anyway.

> Since the statement does use different font sizes and styles, I'd like it to be more than just a text message.

> Has anyone figured out a way for a print previewer to exactly match a paper copy, or do I need to regroup and attack this with some completely other martial art?

> Bill "the nearly bald" Hileman



Sat, 18 Feb 2012 04:49:07 GMT  
 Fonts, wonderful fonts.

Quote:

> I have not done what you are trying to do but the other day I ran into
> a program called PDFCreator which becomes a virtual printer that
> outputs PDF files.
> You could really get fancy if you wanted as PDF files support all
> fonts shapes & sizes, color, pictures of all kinds etc. I think it is
> certainly worth looking at and could provide you with a very robust
> solution.

> The link to download PDFCreator is:

> http://sourceforge.net/projects/pdfcreator/

> Good Luck

> Duke

I appreciate the advice, Duke.  Mike Williams made the same suggestion.


Sat, 18 Feb 2012 05:04:04 GMT  
 Fonts, wonderful fonts.

Quote:



>> I'm trying to send Payroll Direct Deposit Statements to employees
>> from our accounting package . . . The printing of the statements
>> (on paper) is not a problem.  What has me losing what's left of my
>> hair is getting the paper statements into a format suitable for
>> transfer via e-mail . . . I discovered that when you set a printer's
>> font size to eight, it's eight . . . and When you set a picturebox's
>> font size to eight, it's 8.25.

> Actually it's not quite that simple either! In a nutshell, you can
> normally only get a font size that happens to be a whole pixel value
> on the device you are using. If you are getting 8 points exactly on
> your printer then you are probably using a 360 or 720 dpi printer
> (possibly an Epson, although there are many others). That's because
> there are always 72 points per inch and 8 points on a 720 dpi printer
> is therefore 8/72 * 720 = 80 pixels. However on a 600 dpi printer
> (such as a typical HP printer) 8 points is 8/72 * 600 = 66.667
> pixels, which is not a whole pixel value. The nearest you can get on
> a HP printer is therefore 8.04 points, which is exactly 67 pixels on
> that printer. On a computer screen (tpyically running at 96 dpi) 8
> points would be 8/72 * 96 = 10.67 pixels. The nearest whole pixel
> value to that is 11 pixels, which equates on such a machine to 8.25
> points. In other words, you can get a value that is equal to, or at
> least very close to, your desired font size on most printers because
> of their high dpi resolution, whereas on the display, which has a
> relatively low resolution, you often cannot get anywhere near as
> close to your desired value. There is even more to it that that,
> because as well as the point size (which of course is a vertical
> measurement) the "whole pixel" limitation also applies to the cell
> width of each individual character in any string you print, which
> means the horizontal width of a piece of text can be different on
> different devices even when you actually can achieve exactly the same
> font size on both of them! For example 9 points is exactly available
> on all three devices I have mentioned (96 dpi, 600 dpi and 720 dpi)
> but the logical width of a string of text on each of those devices
> can be different, even though they are all using a 9 point font.
> There is a lot more that can be said about this of course, but that's
> the basics of it.  

>> Even if I didn't have the font problem, the picturebox only
>> seems to be able to export to .BMP file format, which
>> makes the file 2 megabytes in size.

> You could add some code to convert the bitmap to a jpeg (there are
> various DLLs available that can help you to do that) but actually if
> you want a quality output then you are better off avoiding bitmaps
> (and jpegs) anyway.

>> so if I want my statements to look "professional" how do
>> I get this beautiful work of art that I create from paper to
>> a format that I can e-mail without having to completely
>> duplicate (well, almost duplicate) all the code used to
>> print the statements?

> There are two approaches I can think of. The first is to create your
> Deposit Statement as a Windows metafile (.wmf, or preferably .emf).
> You can continue to print your own output to the VB Printer Object as
> you are currently doing, or you can instead send the completed
> metafile to your printer using the VB PaintPicture method (the latter
> is the better option because you will be guaranteed that the layout,
> word wrap points, etc, etc are exactly the same on your own printout
> as they would be when your customer prints the metafile you send
> him). Metafiles are vector based and so you will get essentially
> exactly the same high quality printed output as you are getting now.
> You can then email the metafile as a standard .emf file to your
> customer and he can view it directly in his email reader or print it
> or display it from any application he has that is capable of doing so
> (all sorts of different applications). The problem with this approach
> is that VB native Printer Object methods cannot be directed to
> metafiles, and so you would need to use the equivalent API (GDI)
> functions instead, for example using the GDI TextOut method instead
> of the VB Print method, etc. This would cause you quite a bit of
> work, but it would be worth it in the end.  

> The second approach is to continue to print your own copy as you are
> currently doing (using the VB Printer Object and its various methods)
> but to send them to your own printer when you want a hard copy of
> your own and to send them instead to a PDF "virtual printer" when you
> want to produce a pdf file. As I'm sure you are aware, PDF files are
> industry standard document files and they can be viewed by anyone who
> already has or is prepared to download a PDF viewer. PDF printers
> really are very useful things. They are not real printers of course
> (just software "pretend printers") but they install themselves as
> standard Windows printers and they behave as standard Windows
> printers. The PDF file format is in one major way similar to the
> metafile format, at least as far as it is a vector based format, and
> so it produces just as high quality output. Also, you can use exactly
> the same VB printing code on a PDF printer as you use on a real
> printer, so you will not need to amend your current VB printing code
> at all. There are a number of freeware PDF printers around. PrimoPDF
> is a good one, but (as far as I can see) it always pops up a user
> file and settings dialog, which is a limitation in terms of
> automation. Another good one, which has the advantage that it can be
> set to produce a named .pdf file in a specific folder without any
> user interaction, is PDFCreator. So using PDFCreator your VB code can
> use standard VB Printer Object methods (directed to the PDFCreator
> "printer") to create your document as a named .pdf file. Your code
> can then load up that file and email it to your customer. You can
> download PDFCreator at:  

>    http://sourceforge.net/projects/pdfcreator/

> I've just got back from holiday and I haven't really "got my head on"
> yet and there is a lot more that I can say about this stuff, but the
> above should at least get you going.

> Mike

Outstanding, Mike.  That's exactly what I was thinking might be available.


Sat, 18 Feb 2012 05:03:39 GMT  
 Fonts, wonderful fonts.
I use Adobe PDF Writer.  Pricey but it works!
It is really easy, just direct to the PDF "device".
Quote:

> Based on extensive google searching (is that even possible?) I've come to the conclusion that a problem I've encountered is not solvable using the general direction of attack I've been attempting.

> In a nutshell, I'm trying to send Payroll Direct Deposit Statements to employees from our accounting package.  The actual sending via e-mail is not the problem.  The printing of the statements (on paper) is not a problem.  What has me losing what's left of my hair is getting the paper statements into a format suitable for transfer via e-mail.

> What made perfect sense to me was using the exact same routines that send the information to the printer object, and simply redirecting output to a picturebox.  Simple, right?

> Not if you are using an eight-point font, it's not.

> After delving deeper into my own code than I wanted to, I discovered that when you set a printer's font size to eight, it's eight.  When you set a picturebox's font size to eight, it's 8.25.  Doesn't seem to matter which font you use, and my googling has explained why the screen seems unable to do an 8-point font, so if I want my statements to look "professional" how do I get this beautiful work of art that I create from paper to a format that I can e-mail without having to completely duplicate (well, almost duplicate) all the code used to print the statements?

> Even if I didn't have the font problem, the picturebox only seems to be able to export to .BMP file format, which makes the file 2 megabytes in size.  I realize that if I got that far, I could shrink that down a bit by reducing the size of the picturebox from a whole page to 2/3 page, which is all a statement uses anyway.

> Since the statement does use different font sizes and styles, I'd like it to be more than just a text message.

> Has anyone figured out a way for a print previewer to exactly match a paper copy, or do I need to regroup and attack this with some completely other martial art?

> Bill "the nearly bald" Hileman



Sat, 18 Feb 2012 09:47:01 GMT  
 Fonts, wonderful fonts.

Quote:
> I use Adobe PDF Writer.  Pricey but it works!

PDFCreator also works, and it's not pricey!

Mike



Sat, 18 Feb 2012 16:18:36 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Fonts, Fonts and damn Fonts!!!!!

2. font fOnt foNt fonT foNT? argh.

3. <font color=red><font size=256>S.O.S.!!!</font></font>

4. Get width of text in pixels (taking into account font, font size and style)

5. Userform fonts not obeying font property specs

6. Windows Display Font Sizes Vs. Application Font Sizes

7. Large font and small font problem

8. from Small Font to Large Font

9. Common Dialog Fonts = No Fonts Installed

10. Large Font vs Small Font

11. problem small fonts/large fonts

12. Small fonts vs. large fonts

 

 
Powered by phpBB® Forum Software