Skip to main content ↑ ↓
Topic: "Print Preview" Accuracy (Read 11112 times) previous topic - next topic

"Print Preview" Accuracy

I was printing a piece with lots of Boxmark fonts in it but the glissando marks are overlapping the notes, tremelo marks are not position that properly, etc. AND I'm a little bit lazy to correct all of them.

The Print Preview is fine but when it comes to printing some off the texts are off their positions.

Some kind of programing problem right?

Re: "Print Preview" Accuracy

Reply #1 –
More like some kind of Windows problem. Print Preview is accurate only at the highest magnification level.

Scrolling around is still the biggest problem.
Quote from: Rick G. –
... the whole Print Preview subsystem needs a top to bottom rework. NWC3 perhaps?
Quote from: Rick G. –
Print Preview has the look and feel of Windows 3.1
Surely it could at least function like Windows 95.
Registered user since 1996

Re: "Print Preview" Accuracy

Reply #2 –
Print Preview is pretty accurate, except in regard to the length of text expressions and other text. Windows can sometimes apply different text kerning to the text on the display than what is done when actually sending to the printer. This can lead to variations in the Preview.

See also: http://en.wikipedia.org/wiki/Kerning

Re: "Print Preview" Accuracy

Reply #3 –
Quote from: NoteWorthy Online –
Windows can sometimes apply different text kerning to the text on the display than what is done when actually sending to the printer.
The implication of this would seem to be that Preserve Width should never be checked for an Expression: that contains kerned pairs.

If this is true, some mechanism to insert a knowable and repeatable amount of space between objects would seem to be in order.

Perhaps Preserve Width should be a spinbox instead of a checkbox. Possible interpretation could be:

  • -1 (true) - Same as Preserve Width checked.
  • 0 (false) - Same as Preserve Width unchecked.
  • > 0            - Space equal to tenths of a standard note space.

This would be useful for more than just Print Preview problems.
It could also be expanded apply to notes, rests, bars ...
Registered user since 1996

Re: "Print Preview" Accuracy

Reply #4 –
I am not sure that I follow. Preserve width will calculate correctly when printing, as well as in preview. The widths are calculated using the printer device. The discrepancy occurs in the rendering to the screen. The actual text shown in preview might not match the kerning done in the actual print, since the screen device is being used. The widths, however, will match.

Re: "Print Preview" Accuracy

Reply #5 –
If, for example, A and V are each 100 units wide and are kerned, AV will be less than 200 units wide. If, as you say, kerning width varies between 'Preview at maximum' and the 'printer', then the combined width should also vary.
Registered user since 1996

Re: "Print Preview" Accuracy

Reply #6 –
The kerning varies, but the width doesn't.  So "AV" would be 200 units wide in print and preview, although the appearance of the two can vary slightly, since the screen display can use different kerning. It is a subtle, but significant, point.

Re: "Print Preview" Accuracy

Reply #7 –
I think Rick is right, Eric. If the kerning of a kerned pair varies, the overall width of the pair must also vary. Otherwise, the reduction in white space gained by kerning would be lost to white space between the kerned pair and the next letter (or pair). You can see this in the Wikipedia entry you sent Kristopher to. Toward the bottom of the entry, there is an example showing three different kernings of the word "WAR:" unkerned, autokerned, and manually kerned. The words are clearly different widths. This can only happen if the width of the kerned WA pair is itself different from version to version, as both the width of the R and the space between the R and the kerned pair remain constant in all three versions.

I can see one slightly different variant of this scenario. If the width of a kerned pair is defined as constant between screen and printer in any specific given font, the kerning itself could vary between screen and printer without affecting the overall width of the text. What would vary, in this case, would be the position of the second letter of the kerned pair between the first letter of the pair and the next letter to the right. However, the effect would be so subtle that I doubt a user would normally notice; and since overall width would remain the same, it would have no impact on whether or not text went outside the printable space or how it was positioned relative to other objects in the score. So the original problem that Kristopher pointed to would be unaffected.

Cheers (I think),

Bill

Re: "Print Preview" Accuracy

Reply #8 –
Just to be clear, I'll add a short example. Consider this clip:

Code: [Select · Download]
!NoteWorthyComposerClip(2.0,Single)
|Text|Text:"\|"|Font:StaffBold|Pos:-9|Wide:Y
|Text|Text:"AWVAWVAWVAWVAWVAWVAWVAWVAWVAWV"|Font:StaffBold|Pos:-9|Wide:Y
|Text|Text:"\|"|Font:StaffBold|Pos:-9|Wide:Y
!NoteWorthyComposerClip-End

The width of this clip stays constant and identical between a print and a preview. However, the appearance of the text within the widths can vary significantly in preview, as Windows tends to kern the text differently at different zoom levels. The widths, however, are always calculated using the print driver, so are always reliable.

Re: "Print Preview" Accuracy

Reply #9 –
Here's a slightly modified version of your example, Eric:

Quote
!NoteWorthyComposerClip(2.0,Single)
|Clef|Type:Treble
|TimeSig|Signature:4/4
|Text|Text:"AWVAWVAWVAWVAWVAWVAWVAWVAWVAWV"|Font:StaffBold|Pos:-9
|Rest|Dur:4th
|Rest|Dur:4th
|Rest|Dur:4th
|Rest|Dur:4th
|Bar
|Rest|Dur:4th
|Rest|Dur:4th
|Rest|Dur:4th
|Rest|Dur:4th
|Bar
|Rest|Dur:4th
|Rest|Dur:4th
|Rest|Dur:4th
|Rest|Dur:16th
|Rest|Dur:16th
|Rest|Dur:16th
|Rest|Dur:16th
!NoteWorthyComposerClip-End

On my machine, the location of the final "WV" in this example varies in its relationship to the group of 16th rests at different zoom levels in print preview. It doesn't vary very far (the "W" moves from before the first rest to directly beneath it), but it does vary. This indicates to me that the overall width of the text entry changes when you change zoom levels. Is there a different explanation that I'm missing?

Re: "Print Preview" Accuracy

Reply #10 –
In your clip, the text expression does not preserve width, so the "width" property is not relevant. As explained here, the visual manifestation of this text may vary between preview and the actual print, due to kerning or other rounding errors. Any preserved width (if it had any) would not change between preview and print.

Re: "Print Preview" Accuracy

Reply #11 –
Ah. If "preserve width" is checked, it works: the width stays constant. I see your point, and it is (of course) valid. The problem is that many of the uses for text - especially for specialized fonts like Boxmarks - do not work with "preserve width" checked. In my scores it is probably unchecked at least 90 per cent of the time.

And that, I think, is where Kristopher was probably running into trouble. Consider, for example, the arpeggio marks in Boxmarks. If you are arpeggiating a chord with wide spacing, you will have to use several of these marks stacked on top of one another. There is no way to do this using "preserve width," but they stack just fine without it. And appear in different positions in relation to the notes, depending on what zoom level you use.

I don't think this is a problem you need to fix, Eric - as Rick pointed out, it's more like a flaw in Windows that we just have to deal with.

Cheers,

Bill

Re: "Print Preview" Accuracy

Reply #12 –
You're right William, That was the trouble I'm having!

Re: "Print Preview" Accuracy

Reply #13 –
This is one reason for the At Next Note/Bar option in the Alignment tab. It is intended to help line things up without trying to use text character spacing.
 

Re: "Print Preview" Accuracy

Reply #14 –
Hi Everyone.

To throw in my two penn'orth.  I can only echo the comments already made.  Printers work in dots per inch, nowadays 600 or even 1200 dpi.  Windows converts this to pixels per inch, which is dependent on the screen resolution.  For example, 640x480 equates to 72 pixels, 800x600 96 pixels, etc.  Thus, the preview should not be regarded as totally accurate, but a reasonable representation of what the printed copy will look like.  I daresay someone will dig out his old Epson 9-pin, set the screen resolution to 640x480 and reply that the preview is not *identical* to the printout.  To that I will reply with the two words of the third sentence - Windows Converts!

Hope this helps.

Bob Petty (UK)