Uninstalled 2.3.15, reinstalled  2.3.14 and the problem was solved; the checks print like they're supposed to.

Same thing with recent upgrade to Windows 7.  2.3.15 won't print checks.

also windows 7 - 2.3.14 is last to print checks. Also, keyboard accelerators (alt+P do not work

still broken in 2.4.0

I recently upgraded gnucash from 2.2.9 to 2.4.0 on a Vista Home Premium  (service pack 2) computer.  The gnucash help window reports that it was built from svn r19971 on 2010-12-21.

Attempts to print a check result in microscopic printing in the upper left corner of the check in an area about 1 inch square.  This behavior occurred when using a custom format that worked with Version 2.2.9, and with the pre-configured check formats that gnucash 2.4.0 provides.

A custom report was printed with no problems.

I attempted to create a new 'custom' check as a test.  The test check printed in normal size font and placement and I saved the custom format.  However, after restarting gnucash the 'new' custom check format printed the microscopic version.

Re: comment #5...  
As a further test I printed a check to an XPS file and looked at the file.  It showed the same results as the printed checks.  The whole three part check squeezed into about a one inch square area in the upper left corner.

2.4.0 Windows 7 (64 bit) LAN printer HP Officejet 7310xi

Attempts to print a check results in microscopic printing in the upper left
corner of the check in an area about 1 inch square.
All reports printed with no problems.

I'm also getting the tiny check printing using GNUCash 2.4.0 built from svn r19971 on 2010-12-21, running on Windows 7 32-bit. I've tried the new check formats included with 2.4.0 as well as some custom formats that I was using with earlier versions. I've printed both to real printers and to PDFCreator, and get the same results in all cases.  If I scale the PDF file to something like 800%, then I can read the writing, but still can't print checks.

Have you looked at the comments in 
https://bugzilla.gnome.org/show_bug.cgi?id=591177

#591177 is reported as fixed, but the symptoms seem to be very similar.

*** Bug 642248 has been marked as a duplicate of this bug. ***

I guess Thomas meant https://bugzilla.gnome.org/show_bug.cgi?id=591177#c23 : "A workaround would be to change the PDF Creator printer resolution to 72dpi."

Using Windows Vista and I updated to 2.4.3.  This is still happening.  The check prints small in the upper left corner of the page on 5 different printers including PDF and XPS.

I have the same issue. First time user running Windows XP with service pack 3 trying to print to either bullzip pdf driver or a trusty HP LaserJet printer both result in the microscopic print. Has a solution or workaround been found. I SO want to abandon Quicken but I need the check printing function to work.

@ AlanK - I still use 2.3.14 for check printing.

Similar to bug 591177

*** Bug 644815 has been marked as a duplicate of this bug. ***

Christin - If you haven't reproduced the problem, there's a small nuance about it just being the font size - it's the entire scaling  (X, Y coordinates) that seem to be off by ~ factor of 10.

2.4.7 - still broken on my computer

It appears that the conversion from pixels to dots/in is not functioning in Windows.  By setting the dots/in in the printer to 72 or 96 you get a reasonable looking check.  I haven't measured the spacing on a print out to verify that the conversion from pixels to dots/in is mathematically correct.  Font kerning is also incorrect in the "adjusted" printout but this may be a product of the kludge I used to print the reduced dots/in check.

Sorry, I should have said "text point size" instead of pixel.

I think the Gnucash program is great and just installed the latest version on a windows XP machine.  I too have a problem with printing checks. The output looks like the page size is set too small and the font size is too small, so the entire check is about 1/2" long by .1" down and just looks like a smudge.  I played with the custom settings and finally got a small version by increasing the font size to the maximum and using settings of 45" and 63" to go half way across an 8.5" page.  Obviously the conversion to inches is wrong and the paper size and font size is possibly linked to that incorrect conversion.  Like the Hubble telescope when the two teams each used a different standard of measurement.  I use a laser printer and also output it to a Pdf file and it is still too small, although I did get it up to half of it's normal size.  I might suggest seeing if a standalone program called "CheckWriter" by Gulf Coastal Software, gcs@nym.alias.net, would let you incorporate their program into yours since it is freeware and works great for printing checks in Windows, even allowing dragging of the fill-in sections to match the check form.  Otherwise, I wish you would take this issue out of the "UNCONFIRMED" category and see if a solution can be found. I can't believe that the people who have reported this over the last year are the only ones with the problem. I would attach a copy of the using the quickbooks form output, but it's too small to see, so there's no point.If David Hampton cannot reproduce it on his windows machine (I am running XP, SP3), then maybe he could share his settings that work to print a normal check so we could try it. I know the programmers work hard and I'm not criticizing them, just trying to see if something will help fix this.

I think the Gnucash program is great and just installed the latest version on a windows XP machine.  I too have a problem with printing checks. The output looks like the page size is set too small and the font size is too small, so the entire check is about 1/2" long by .1" down and just looks like a smudge.  I played with the custom settings and finally got a small version by increasing the font size to the maximum and using settings of 45" and 63" to go half way across an 8.5" page.  Obviously the conversion to inches is wrong and the paper size and font size is possibly linked to that incorrect conversion.  Like the Hubble telescope when the two teams each used a different standard of measurement.  I use a laser printer and also output it to a Pdf file and it is still too small, although I did get it up to half of it's normal size.  I might suggest seeing if a standalone program called "CheckWriter" by Gulf Coastal Software, gcs@nym.alias.net, would let you incorporate their program into yours since it is freeware and works great for printing checks in Windows, even allowing dragging of the fill-in sections to match the check form.  Otherwise, I wish you would take this issue out of the "UNCONFIRMED" category and see if a solution can be found. I can't believe that the people who have reported this over the last year are the only ones with the problem. I would attach a copy of the using the quickbooks form output, but it's too small to see, so there's no point.If David Hampton cannot reproduce it on his windows machine (I am running XP, SP3), then maybe he could share his settings that work to print a normal check so we could try it. I know the programmers work hard and I'm not criticizing them, just trying to see if something will help fix this.

to docduke:  The documentation is at 

http://code.gnucash.org/docs/guide/check_format_info.html#check_format_notes

The splits are printed as multiple lines moving 'up' from the defined location.  Take notice of the note at the bottom of the page.  Also note that printing splits only makes sense with voucher checks because there is not enough space otherwise.  The voucher example that comes with gnucash doesn't use split printing.

I can confirm the problem and have noticed that running on XP sp3:

1.  the printer PDFCreator ( http://sourceforge.net/projects/pdfcreator/ ) does not work.  ( meaning that it fails 'small' the same as my printer )

2.  a custom format seems to work correctly on my HP1022 and PDFCreator.  I only tried units of points, which is the units in the check format files.  

Although the 'custom' interface doesn't include all the capabilities of a check format file, I think it is sufficient as a workaround for most purposes.

I am not able to help with this because I don't have a windows development environment.

I noticed that the file for the check forms are classified as "recovered file fragments" in the detailed directory view.  I then found that the extension used for the check forms, namely, "chk", is reserved for Windows as the name for recovered files when there's a program crash.  I wonder if that affects how the files open and possibly cause the weird behavior when we try to print checks.  Is is possible to change the extension to something else in the Windows version so there are accepted as intact files?  Here is Windows explanation of a "chk" extension on a file: So what is a CHK file?  Well, any time a program or Windows crashes, any files that were open are not closed properly. Part of closing is writing all the file location information in all the right places. Without this info, Windows can't find all the parts of the file. When SCANDISK or CHKDISK is run, all the parts are identified as "lost file fragments" and converted (if you want) into CHK files. Face it. Stuff crashes all the time. If you only run SCANDISK once a month, you get a month's worth of old crash junk. If you were working on (and lost) something important just before a crash, you might want to try to recover any data from any CHK files that exist. On the other hand, if you aren't in a state of panic over lost data, just delete any CHK files. A handy tip: Keep your disk defragmented. That way if you ever do lose it all, the lost file fragments will be more likely to be complete files.

(In reply to comment #23)
> to docduke:  The documentation is at 
> 
> http://code.gnucash.org/docs/guide/check_format_info.html#check_format_notes
> 
> The splits are printed as multiple lines moving 'up' from the defined location.
>  Take notice of the note at the bottom of the page.  Also note that printing
> splits only makes sense with voucher checks because there is not enough space
> otherwise.  The voucher example that comes with gnucash doesn't use split
> printing.
> 
> I can confirm the problem and have noticed that running on XP sp3:
> 
> 1.  the printer PDFCreator ( http://sourceforge.net/projects/pdfcreator/ ) does
> not work.  ( meaning that it fails 'small' the same as my printer )
> 
> 2.  a custom format seems to work correctly on my HP1022 and PDFCreator.  I
> only tried units of points, which is the units in the check format files.  
> 
> Although the 'custom' interface doesn't include all the capabilities of a check
> format file, I think it is sufficient as a workaround for most purposes.
> 
> I am not able to help with this because I don't have a windows development
> environment.


To docduke:  Could you provide the "x" and "y" coordinates that you say worked in your #2 paragraph please?

I copied the values from the quicken.chk file (Quicken/Quickbook US Letter).

In the Print Checks dialog, select Custom for Check Format.  Go to Custom Format tab and enter the values from the quicken.chk file below:
  
[Top]
Guid = 67b144d1-96a5-48d5-9337-0e1083bbf229
Title = Quicken/QuickBooks (tm) US-Letter
Rotation = 0.0
Translation = 0.0;4.0
Show_Grid = false
Show_Boxes = false

[Check Positions]
Height = 252.0
Names = Top;Middle;Bottom

[Check Items]
Type_1 = PAYEE
Coords_1 = 90.0;102.0;400.0;20.0

Type_2 = AMOUNT_WORDS
Coords_2 = 90.0;132.0

Type_3 = AMOUNT_NUMBER
Blocking_Chars_3 = true
Coords_3 = 500.0;102.0

Type_4 = DATE
Coords_4 = 500.0;67.0

Type_5 = NOTES
Coords_5 = 50.0;212.0

Type_6 = ADDRESS
Coords_6 = 90.0;192.0

Units must be set to Points ( at the bottom of the Custom Format tab ).

For fields that you do not want to print ( such as SPLIT_AMOUNT ), the position must be set off the page.  I used x,y = 0,900 to put it off the bottom of the page.

Print then works, and the custom values are remembered the next time gnucash starts.

Using Save Format and then later using the new .chk file does not work: same problem as the other .chk files.

(In reply to comment #26)
> I copied the values from the quicken.chk file (Quicken/Quickbook US Letter).
> 
> In the Print Checks dialog, select Custom for Check Format.  Go to Custom
> Format tab and enter the values from the quicken.chk file below:
> 
> [Top]
> Guid = 67b144d1-96a5-48d5-9337-0e1083bbf229
> Title = Quicken/QuickBooks (tm) US-Letter
> Rotation = 0.0
> Translation = 0.0;4.0
> Show_Grid = false
> Show_Boxes = false
> 
> [Check Positions]
> Height = 252.0
> Names = Top;Middle;Bottom
> 
> [Check Items]
> Type_1 = PAYEE
> Coords_1 = 90.0;102.0;400.0;20.0
> 
> Type_2 = AMOUNT_WORDS
> Coords_2 = 90.0;132.0
> 
> Type_3 = AMOUNT_NUMBER
> Blocking_Chars_3 = true
> Coords_3 = 500.0;102.0
> 
> Type_4 = DATE
> Coords_4 = 500.0;67.0
> 
> Type_5 = NOTES
> Coords_5 = 50.0;212.0
> 
> Type_6 = ADDRESS
> Coords_6 = 90.0;192.0
> 
> Units must be set to Points ( at the bottom of the Custom Format tab ).
> 
> For fields that you do not want to print ( such as SPLIT_AMOUNT ), the position
> must be set off the page.  I used x,y = 0,900 to put it off the bottom of the
> page.
> 
> Print then works, and the custom values are remembered the next time gnucash
> starts.
> 
> Using Save Format and then later using the new .chk file does not work: same
> problem as the other .chk files.


Thanks for that information.  I played with it on my Windows XP which has the problem with tiny fonts and came up with a solution, although not totally satisfactory since it still is about size 6 font in the end.

I changed the font in Preferences to the largest available: 72
I then created a new custom file which I saved when I was finished and these are the coordinates that worked for me on a laser printer:

Show_Grid=false
Show_Boxes=false
Rotation=0
Translation=10;3;

[Check Items]
Type_1=PAYEE
Coords_1=450;825;
Type_2=DATE
Coords_2=3150;550;
Type_3=AMOUNT_WORDS
Coords_3=1650;1025;
Type_4=AMOUNT_NUMBER
Coords_4=4050;825;
Type_5=ADDRESS
Coords_5=450;1700;
Type_6=NOTES
Coords_6=450;2500;
Type_7=MEMO
Coords_7=550;4500;
Type_8=SPLITS_AMOUNT
Coords_8=2500;6000;
Type_9=SPLITS_MEMO
Coords_9=350;5500;
Type_10=SPLITS_ACCOUNT
Coords_10=1500;5000;

I also found that I could open the .chk files with "wordpad" even though Windows thinks these files are fragments that are useless and not useable by its programs and then add more if needed.

I still think the module needs work.  Why can't it use the windows default page size and font?  Just like printing of reports does?  When I changed the font in preferences, it only affected the print checks option.  Reports print normal and not tiny.

At any rate, thanks for a great program except for this one bug.

If you use wordpad to edit a chk file in windows xp, only "save" it in the file dropdown.  If you use "save as", it will change format and make it useless.

I played with this some more and found a workaround that works for my computer and printer.  I found a check form on the internet by Heckert and want to give him credit for the basic layout.  I used wordpad and "save" (not "save as") to adjust the font size and location until I got this which works with a check form that is close to a Quicken form.  Font size 80 is close to font size 12 in the usual sizes due to the problem with reducing the size of everything in the print check module.


[Top]
Guid=a3ad29b733ba8faa46721c93fff288ce
Title=Heckert 3part nolines
Show_Grid=false
Show_Boxes=false
Rotation=0
Translation=10;3;

[Check Items]
Type_1=PAYEE
Font_1 = sans 80
Coords_1=450;825;

Type_2=DATE
Font_2 = sans 80
Coords_2=3150;550;

Type_3=AMOUNT_WORDS
Font_3 = sans 80
Blocking_Chars_3 = true
Coords_3=1650;1025;

Type_4=AMOUNT_NUMBER
Font_4 = sans 80
Blocking_Chars_4 = true
Coords_4=4050;825;

Type_5=ADDRESS
Font_5 = sans 80
Coords_5=450;1700;

Type_6=NOTES
Coords_6=450;2500;

#Type_7=MEMO
#Coords_7=550;2500;


#Type_8=TEXT
#Text_8 = 
#Coords_8=1650;1075;

Type_9=TEXT
Text_9 = THE SUM OF
Font_9 = sans 80
Coords_9=1000;1025;

Type_11=TEXT
Text_11 =
Coords_11=500;110;

Type_12=TEXT
Text_12 =
Coords_12=90;125;

# stub 1

Type_13=SPLITS_MEMO
Coords_13=450;2700;

Type_14 = PAYEE
Coords_14= 550.0;3000.0

Type_15 = DATE
Coords_15 = 3150.0;3000.0

Type_16 = NOTES
Coords_16 = 450.0;4000.0

Type_17 = TEXT
Text_17 = Total
Coords_17 = 200;3600.0

Type_18=SPLITS_AMOUNT
Coords_18=1500;3600;

Type_19 = AMOUNT_NUMBER
Coords_19 = 800.0;3600.0

# stub 2

Type_20 = PAYEE
Coords_20 = 450.0;4500.0

Type_21 = DATE
Coords_21 = 3150.0;4500.0

Type_22 = NOTES
Coords_22 = 450.0;5210.0

Type_23 = TEXT
Text_23= Total
Coords_23 = 3000;5725.0

Type_24=SPLITS_AMOUNT
Coords_24=3500;5000;

Type_8 = AMOUNT_NUMBER
Coords_8 = 3500.0;5725.0

Type_7=SPLITS_MEMO
Coords_7=450;4100;

Type_10=SPLITS_ACCOUNT
Coords_10=1500;5000;

Hope this helps someone else and saves them several hours of trial and error.

You will need a saved check file to start with since I don't think you can create a ".chk" file in windows.  That's reserved for the system.  So just create a custom check in Gnucash and save it with a name you like for your system, locate and open it with Wordpad, delete the original contents, then copy and paste the commands I listed into it click "save". That should work unless you need to change the guid info.  You can find location info and guid changing info in the comments at the beginning of this bug thread 631611.

Comment 23 gives the location info and guid info.


The documentation is at 

http://code.gnucash.org/docs/guide/check_format_info.html#check_format_notes

One more thing about Comment 29, I didn't carry the font command all the way through because I set the system font in preferences to the maximum already and that handles the stub font, 72 approximates size 10.

On my machine the scaling ratio is 600/72 -> 8.333.  This is based on my printer DPI of 600 ( I think ;)

So there seems to be three basic ways to hack this problem:

1.  Copy an existing .chk file, edit, and scale everything by 8.333  e.g.  Font=sans 10 becomes Font=sans 83.33 and so on for all the numbers except rotation.  Add a Font= line in the [Top] section if not there.  This sets a default font for all items.  The Guid also has to be changed, and in true hacking spirit I just changed the last digit.

There are previous comments describing editing. I used WordPad.  Briefly:

The original file is in c:\Program Files\gnucash\share\gnucash\checks and the edited file is in c:\Documents and Settings\[your user name]\.gnucash\checks.  Or just save a custom format and edit that file ( in this case the Guid is fine ).

2.  Change the printer 'resolution'.  I can do this with PDFCreator by selecting Preferences in the print dialog, selecting Advanced and changing Print Quality from 600DPI to 72DPI.  Unfortunately, I haven't found a way to save this setting.

3.  Use custom format.

Notes:
The only things that don't work with method 1 is DateFormat ( it prints too small ) and Show_Grid=true.  This is not likely to be a problem for most.

Everything works with method 2.

Method 3 has severely limited function e.g. no stub printing, no voucher checks.

*** Bug 662688 has been marked as a duplicate of this bug. ***

Still a problem/bug on 2012-04-10.  Using GNUcash 2.4.10 on Windows 7 Professional 64 bit.

Man... this is annoying.  Check printing worked great on my Ubuntu machine!

I finally managed to track this bug down. It turns out I was looking in the wrong place for the cause.

Lesson learned: never ever use cairo_identity_matrix on the cairo_t that is returned from gtk_print_context_get_cairo_context. It will totally mess up the scaling of a page to print on Windows.

It will be fixed in 2.4.11.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=631611. Please update any external references or bookmarks.