Skip to main content
Topic: Staff lines missing when print (Read 7596 times) previous topic - next topic

Staff lines missing when print

I just installed version 2.0.  I've been using 1.75 for a long time.

I know this can't be right; but, this is what I'm seeing.  Only the first two staffs on a page print the staff lines.  All the rest of the staffs staff lines are invisible; but, the notes, text, key signatures, clefs, etc are all there.  Just no staff lines.  They do print in the print preview though.  The print preview looks perfect.  These are just regular solo instrument staffs.

What am I doing wrong....  Did I accidentally turn on something...
Thanks for any help.

Re: Staff lines missing when print

Reply #1
FAQ - Disappearing Staff Lines

You may also want to try printing with the Beta version of the viewer.
This new version uses a new technique for most line drawing in the editor as well as printing. This can help with print driver problems, as well as improve your results when printing or copying notation to PDF or other applications.
Registered user since 1996

Re: Staff lines missing when print

Reply #2
Another possible workaround is to print to a pdf file and then print the pdf file. There are many programs out there that will print to pdf: the one I use is called PDF reDirect (http://www.exp-systems.com/). It's freeware and works wonderfully. Others on this forum have their own favorites. Just be aware that sometimes printing to pdf introduces the disappearing staff line problem instead of fixing it, so it's not always a solution.

Bill

Re: Staff lines missing when print

Reply #3
I had a similar problem.  At first it loked like I was just missing all (horizontal) staff lines after the first printed staff.  But then I noticed the (vertical) note lines were missing too.  So basically all horizontal or vertical lines were missing (or clipped) after an inch or so down the page.  The problem seemed to go away when I upgraded to NWC 2.0.  But it just came back again, this time with an inch or so band at the top of the page *and* a couple-inch band in the middle of the page where the horizontal/vertical lines made it into print.  Outside of these bands, the staff lines and note lines disappear, even in mid-staff and mid-note.  Again, all the non-horizontal and non-vertical stuff prints fine, and everything looks fine in print preview.

I happened to change the staff size (Page Setup, Fonts, Change.., Staff Size) to scale the music better on the page, and the problem seemed to go away.  You might try this, and see if it helps.

Re: Staff lines missing when print

Reply #4
To clarify a bit, perhaps....

What is going on here is a printer driver problem, not a problem with NWC (although NWC is not entirely blameless).

All printers must use a mathematical algorithm to translate the image on your screen (usually 72 dots per inch) to ink spots on the page (often 300 dpi; other resolutions are not uncommon, but they are almost always exact multiples or divisions of 300). Unfortunately, the ratio between screen dots and printer dots is not a simple one (72 doesn't go into 300 evenly), so what appears on your page can only be an approximation of what appears on your screen. It's basically a rounding-off problem. The page contains many pixels that never appeared on the screen, but have been interpolated in between the screen dots; at the same time, some screen pixels are not going to make it to the page at all.

Because of the method NWC uses to draw straight horizontal and vertical lines, they tend to be among the pixels that are dropped out by the algorithms used by a few printer drivers. It's a spotty problem because these algorithms are recursive, so the rounding-off error accumulates as you go down the page. This can change both the horizontal and vertical position of the dropouts. That's why the lines may appear at the top of the page but disappear partway down....and may reappear a few inches later. It's also why changing the staff size may help, as purdue found out. Altering the scale of the objects the driver is dealing with will cause its algorithm to treat them differently. Usually increasing the scale helps, but I would guess that there are cases where a larger staff size actually causes the problem to appear, or to get worse. 300/72 is just not a simple relationship.

The Beta version of the NWC Viewer that Rick pointed you to a few posts back uses a different line-drawing method that is more compatible with some printer driver algorithms, and is thus less likely to lead to dropouts. Programs that convert other formats to pdf are also printer drivers - they just print to a file instead of to a piece of paper - and they usually use a more sophisticated algorithm that is less likely to drop significant pixels out. This is why printing to pdf may also solve the dropout problem. The downside of the pdf solution, though, is that to actually transfer a pdf to the printed page you will still have to go through your printer's driver, and this second translation may create dropouts of its own.

This post isn't going to solve your problem, but I hope it will help you understand why it occurs.

Cheers,

Bill

Re: Staff lines missing when print

Reply #5
To clarify a bit, perhaps....

What is going on here is a printer driver problem, not a problem with NWC (although NWC is not entirely blameless).

All printers must use a mathematical algorithm to translate the image on your screen (usually 72 dots per inch) to ink spots on the page (often 300 dpi; other resolutions are not uncommon, but they are almost always exact multiples or divisions of 300). Unfortunately, the ratio between screen dots and printer dots is not a simple one (72 doesn't go into 300 evenly), so what appears on your page can only be an approximation of what appears on your screen. It's basically a rounding-off problem. The page contains many pixels that never appeared on the screen, but have been interpolated in between the screen dots; at the same time, some screen pixels are not going to make it to the page at all.
Perhaps not. Printed output is not "interpolated" from the screen. No one would be satisfied with upscaling 96 or 120 dpi (common screen resolutions) to modern printer resolutions.

NWC2 (and the viewer) produce Encapsulated MetaFile output through calls to Windows system functions. The driver, screen or printer, maps the EMF coordinates into its own space. This is inexact and can lead to dropouts. PDF drivers have been around for a long time and have solved most of these problems. New drivers take time to get the bugs out.

The 72/300 scaling problem has nothing to do with the screen. It has to do with the translation of points (1/72 inch) to the output device's resolution. Most printers use a multiple of 300dpi which introduce rounding errors. Canon printers use a multiple of 360dpi which is exact (1 point = 5 dots). This often results in a different number of measures in a system when changing printer resolutions. Designing a song in NWC2 that will have the same layout on a variety of printers is a daunting challenge. This is one reason that I have requested that NWC2 have a "ragged right" option so that one can see if a system is pushing the limit of the print width.

A special problem exists for ink-jet printers: clogged jets. They happen, and can wipe out an entire staff line. One clogged jet will make a staff line look different than others. I suspect that many of the problems reported in this forum are due to clogged jets, yet the poster seldom specifies the printer in his post. I doubt that the droput problem even exists with mature drivers on laser printers.
Registered user since 1996

Re: Staff lines missing when print

Reply #6
Quote
A special problem exists for ink-jet printers: clogged jets. They happen, and can wipe out an entire staff line. One clogged jet will make a staff line look different than others. I suspect that many of the problems reported in this forum are due to clogged jets, yet the poster seldom specifies the printer in his post. I doubt that the droput problem even exists with mature drivers on laser printers.
My printer is an HP Officejet J6450.  And I know what a clogged jet problem looks like.  :-)  My problem (and I suspect the original poster's problem too) featured an extrememly clean printout, with perfect clefs/noteheads/accidentals/keysigs/timesigs/dynamics/text/etc, with no sign whatsoever of a "white line" through any graphic where the clef line was intersecting with it.  It is very clearly a printer driver problem, which seems to be most easily fixed by tweaking the scaling.  (My computer uses Windows XP, so it's not that "immature".  And I can fax you the printout if you like :-) )

Re: Staff lines missing when print

Reply #7
It is very clearly a printer driver problem
Agreed, and the driver was written by HP, not Microsoft. When I wrote of "maturity", I was refering to the printer driver, not the operating system. Sorry for the confusion.

If your printer is anything like my HP 712C, HP's website will have half a dozen drivers that will work with it. You should try a few. You may find that some are better than others. You might also try printing with the Beta Viewer, which uses a different method to draw lines.

You may also find that spooling the document is different than sending it directly to the printer.
Registered user since 1996

Re: Staff lines missing when print

Reply #8
Good evening, Rick -

As I was writing my last post, I made a little bet with myself that you would respond to it, and it looks like I won. ;-)

You are, of course, right re the actual pixels per inch counts of monitors. Back in the good old days of CRT monitors, I remember checking carefully while purchasing one to make sure I was getting at least a dot pitch of 0.028mm. That would be a pixel count of roughly 90 dpi. My XP laptop offers a choice between resolutions of 96 and 120. Modern hi-res monitors do considerably better than that.

All this is true but not particularly relevant, because in a text-based program like NWC, as you know, the effective dpi is always 72, corresponding to one pica per pixel. Text is remapped to a "screen inch" that redistributes the pixels according to the ratio between the actual dpi and 72. So I think everything I said holds. But I think the original way I said it was maybe a little less confusing to non-techies.

However, thanks for the info re Canon printers. That was a piece I didn't know. Interesting approach to the remapping problem. Mate a Canon printer to a Mac monitor, and I guess mapping problems would disappear.

Cheers,

Bill

Re: Staff lines missing when print

Reply #9
All this is true but not particularly relevant, because in a text-based program like NWC, as you know, the effective dpi is always 72, corresponding to one pica per pixel.
I don't know any of this. I wouldn't classify NWC as "text-based". It uses fonts, but it also draws lines and bezier curves.

I don't understand why the "the effective dpi is always 72".
One pica per pixel might make for a nice scoreboard, but it is a bit coarse for a printer.
Registered user since 1996

Re: Staff lines missing when print

Reply #10
One pica per pixel might make for a nice scoreboard, but it is a bit coarse for a printer.
Perzactly. Which is why printers need to remap. Which is where the 72/300 ratio wreaks its little havoc on line width.

I guess whether you call NWC text-based or not is a matter of definition. The program does draw lines and beziers, but its primary function - note and musical symbol placement - is done by fonts, and the staff scaling is in picas so that the staff lines and the symbol fonts will match. I think that qualifies it as text-based, but I wouldn't argue over it. The point is the fonts, and the scaling by picas. There's that 72 again.

By "effective pixels" I mean the way a text program divides up inches in the background, which is by picas. These are then mapped to the 96 (or 90, or 120, or whatever) actual pixels in an inch of the screen in such a way that the inch is effectively divided into 72 pixels. Since pixels are discrete, this means that sometimes a background pixel corresponds to X screen pixels and sometimes it corresponds to X+1. It's a standard rounding-off problem. For example, on a 120 dpi screen, 1 pica = 1.67 dots. So a one-pica-wide line is actually two screen dots wide, but a 2-pica-wide line is only 3 dots - just one dot wider. A 3-pica line is 5 dots wide, a 4-pica line is 7 dots wide, and so forth. Note that you won't see any lines 1 pixel wide, 4 pixels wide, 6 pixels wide, etc. They don't match any pica measurements. So the effective division of the inch is into 72 parts. And maybe those calculations will help purdue and others understand why their lines are sometimes disappearing. When rescaling for the printer drops a thin line into one of those gaps - which are, of course, bigger when you're scaling from 72 to 300 than when you're scaling from 72 to 120 - not all drivers are able to make the adjustment.

Cheers,

Bill

Re: Staff lines missing when print

Reply #11
A pica is 1/6th of an inch.

AFAIK, screen resolution has nothing to do with printer resolution. The printer driver is not constrained in any way by the screen driver.

In any case, and for reasons I have never understood, NoteWorthy scales its system font by 5/4. Thus, a Treble Clef in 16pt Staff metrics is the same size as a 20pt Treble Clef in User1 (or WordPad). It could be that, way back in 1993, Eric had a 180dpi printer and scaling the sytem font eliminated rounding errors.
Registered user since 1996

 

Re: Staff lines missing when print

Reply #12

I guess the only appropriate response to this is [glow=red,3,300]:-[[/glow]

You'd think someone who has been around the publishing industry as long as I have (thirteen books) would know the difference between a point and a pica. I could plead the lateness of the hour when I was posting, but actually I never could learn that, for some stupid reason. (You could talk to the people who worked with me when I was editing the Oregon Chapter - Sierra Club newsletter....but I wish you wouldn't.)

That aside, the point (!) remains. And you are correct that what happens on the screen doesn't affect the printer driver. The problem is that what happens in the background affects both of them - and affects them differently. The background, which is being constructed to a scale of one inch=72 *points* (I think I got that right this time) is being mapped to a screen inch of 72 points, but to a printer inch of 300 dpi (or whatever the printer is set for). The screen inch dimensions are equivalent to the background dimensions, but the printer inch dimensions are an awkward ratio of the background dimensions, and that's why you get dropouts in the printer that you don't see on the screen.

I hope that clarifies things. And thanks for pushing me until my over-simplified first explanation began to take on some meat.

I hadn't noticed the staff scaling oddity, but you're right. I wonder.....?

Cheers,

Bill