On 17 Feb 2009 at 9:49, dhbailey wrote:

> David W. Fenton wrote:
> > On 17 Feb 2009 at 10:09, Johannes Gebauer wrote:
> > 
> >> On 17.02.2009 David W. Fenton wrote:
> >>> The reason why this bothers me is because it means data is constantly 
> >>> being discarded and recreated. This means that there will be a 
> >>> certain level of fragmentation in the file's internal structures 
> >>> (whether in RAM only, in temp files only, or in the actual file image 
> >>> saved on the hard drive, I don't know). This kind of fragmentation is 
> >>> the kind of thing that can lead to file corruption, so I want to 
> >>> avoid as much of that as possible.
> >>
> >> Well, I am not an expert on Finale's data structures, but I am pretty 
> >> sure updating the layout actually changes nothing in the file itself. 
> > 
> > You can't seriously believe that, can you? Before my update layout, 
> > pages displayed the problem. After I updated, the problem went away. 
> > I saved the file, of course, and when I open it now, it doesn't 
> > display incorrectly. This indicates to me that data was written to 
> > the file.
> 
> Actually, I believe that Finale gets it's print data from 
> the graphics card 

*All* WYSIWYG applications use the rasterizer of your printer driver 
for the screen calculations, and it has always been that way. I don't 
see what this has to do with anything, though. The problem was not a 
screen display issue -- it was a case of completely ignoring a set 
page layout that had already been stored in the data file (and 
retrieved and reprinted more than once, BTW).

> -- at least it did when I first started 
> using it because I had a problem with printing and contacted 
> tech support and they told me that and gave me a workaround 
> until I updated the drivers for my graphics card.

Yes, bugs in video drivers can cause problems with printing.

> So if the printing does indeed get its data from the 
> on-screen realization, then saving the file and re-opening 
> it, even without updating the layout might have solved the 
> problem.

But what would have caused the layout to get out of whack in the 
first place? I have not changed printer or video drivers between the 
last time I printed the file, and the editing session where I changed 
a few notes.

> I'm not convinced that update layout does anything other 
> than force the graphics card to redraw from the file, 
> instead of keeping possibly erroneous data in the memory 
> chips of the graphics card, which would cause the layout 
> problems.

Really? Manually updating data changes measure widths, e.g., spacing 
measures that are not filling up a whole system (or are scrunched up 
on one side) to evenly fill the whole system, and recalculating 
automatic system breaks based on measure widths that have changed 
since the last layout update. Yes, of course, for display purposes, 
there's going to have to be interaction with the printer driver, but 
these are not display issues -- these are issues of where the bar 
lines fall horizontally in a system, and where the systems break. 
That's data that *must* be stored in the data file, seems to me, as I 
can't conceive of how it could be recalculated correctly upon re-
opening the file if it has not been stored already.

-- 
David W. Fenton                    http://dfenton.com
David Fenton Associates       http://dfenton.com/DFA/

_______________________________________________
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Reply via email to