Re: AW: AW: [Finale] Converting from Sibelius to Finale
dc wrote: David W. Fenton écrit: But, again, the problem as I see it is *not* with Finale, but with Acrobat's incorrect line smoothing. I don't know why Finale sends multiple thin lines instead of a single line with a particular thickness to the print driver, but perhaps there's a reason for that. This is what MM says. But then why doesn't Sibelius have the problem? A few years ago, someone explained, after looking at the Postcript description, that lines (staff lines, beams) in Finale were made of several thin lines. Whether this is true or not, the fact is that at certain magnifications you can see these multiples lines in staff lines, beams, etc. But not in Sibelius PDFs (nor in MacFinale PDFs). And this is what makes for the crappy look. On the other hand, there is no difference in the look of all the fonts, including the music fonts. As someone else pointed out, the program itself (Finale or Sibelius) generates the data it needs to get the image on the screen, and then that is sent to the OS or to the Postscript interpreting program. Apparently Finale is using a particular routine (possibly subcontracted from a third party?) to generate its Compile Postscript Listing but when the program is set to print to a PDF printer such as Distiller or PDF995 or some other pdf creation program, the image data from Finale is interpreted by a different routine. The difference between Sibelius and Finale when turned into PDFs may simply be the different approach each program takes to generating the lines to show onscreen. Those differing approaches to generating the original data may explain the differing results when printing to PDF files. So I guess one could claim that the fault may lie with Finale, when the same PDF program is used to print to pdf from Sibelius and from Finale and the on-screen results are different. But the fact that some people are seeing great onscreen pdf files from Finale while others aren't says to me that the problem lies in the different approaches to PDF creation that the different 3rd-party pdf creation applications take. And that isn't Finale's fault. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
dc wrote, on 9/24/2007 2:02 AM: [EMAIL PROTECTED] écrit: This does not address the fact that Finale's Compile Postscript Listing function produces a perfect display. Finale prints to Postscript and compiles Postscript quite differently. Does this work with any kind of font? TT or PS or OT? Yes, it works with all of them. I know because I use a mixed library of fonts (about 7,000 of them, actually). So far (with Finale 2K7) it has compiled listings that produces perfect PDFs. The easiest sequence for me (because it's so fast) is to compile the listing, drop the PS file onto GhostScript (which unlike Distiller, doesn't pre-load the whole font library), and have GhostScript convert to PDF. When I have multiple documents (several movements, title page, cover, instructions done in, say, MSWord) then I go to docPrint Pro (about $40) to assemble the whole mess into a single PDF document. docPrint Pro reads EPS, PS, PDF, DOC, and numerous other formats. As I say, the only thing Finale's Compile Postscript Listing doesn't do is compile the TIFF graphics with it. Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
dc wrote, on 9/24/2007 8:12 AM: I can't get Compile PS to work. Finale crashes if I include the fonts. And it gives nice staff lines if I don't, but without the fonts (except Maestro, for some reason)... The resulting PDF has only two fonts listed: Maestro and Courier. Courier is the normal substitute for missing fonts. Finale itself crashes, not the compilation process? Faced with this issue, here's what I would do: I would load my usual template and try to compile a new (otherwise blank) document (and save it under a usable name). If the template compilation crashed, I'd do a data check on the document, especially for missing fonts (save under a new name, always). If the template still crashed after a missing font check, I'd go into the expressions, articulations, lyrics, default fonts (tuplets, too), etc., and check their fonts -- and swap fonts on anything that might not be there that data check doesn't find. For some reason, data check doesn't seem to find fonts that are in the Windows substitution library. I always check documents for the old Times and Helv names and get rid of those; Helv was always in the tuplet definitions. (It would be easier to use Tobias's TGTools font lister, but that feature always crashes for me.) With such a large library, I also find defective fonts now then, as well as mis-named fonts. (Free fonts in particular suffer from those who fail to change the Postscript font name when working with another base font.) If the template didn't crash (or was fixed by data check and font swaps), I would then begin adding expressions or other items that I used in the document that wouldn't compile -- until it crashed again. (And keep saving under new names!) That would identify the first culprit font. I'd continue until all the fonts either passed or crashed it. When I finally got through a clean compilation, I'd load up the original document and go through the font-cleaning process: data check, font swaps, etc., until that document passed. Once satisfied by all this, I'd go back to my template and clean it of bad fonts, and save it as my new default template. Can you tell I've been through this kind of stuff before? :) Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
On 24 Sep 2007 at 8:02, dc wrote: David W. Fenton écrit: But, again, the problem as I see it is *not* with Finale, but with Acrobat's incorrect line smoothing. I don't know why Finale sends multiple thin lines instead of a single line with a particular thickness to the print driver, but perhaps there's a reason for that. This is what MM says. That's interesting. But then why doesn't Sibelius have the problem? Obviously because they use different methods for rendering than Finale, methods that Acrobat Reader has not broken in later versions. A few years ago, someone explained, after looking at the Postcript description, that lines (staff lines, beams) in Finale were made of several thin lines. You can easily see this in my PDFs at very high magnifications. Whether this is true or not, the fact is that at certain magnifications you can see these multiples lines in staff lines, beams, etc. But not in Sibelius PDFs (nor in MacFinale PDFs). And this is what makes for the crappy look. On the other hand, there is no difference in the look of all the fonts, including the music fonts. Look, the way Finale did it worked until someone else broke it. Granted, the logic behind Finale's method is obscure to me and seems, well, kind of backward (a 1990s-era approach to the problem of putting different line thicknesses on screen and on paper), but the point is that it worked in the past just fine, and somebody else did something that broke it. That said, given that there's a different way to do it that would entirely eliminate the problem, I don't have an explanation of why MM doesn't change it. But my bet is that there are reasons for this, reasons that have to do with the internal architecture of Finale and how it communicates with graphic rendering devices (i.e., screen and printer). That it hasn't been fixed probably means that it isn't as simple as it looks from the outside. I hate it when my clients tell me that some alteration to the application I programmed for them will be easy. They don't know jack about what it takes to make the changes they request. And neither do we. The programmers at MM are not bad people -- they are just like all of us, with limited time to put into a myriad of problems. Given that those Finale-generated PDFs print just fine, I can see why they wouldn't worry too much about fixing the onscreen display, especially if such a fix would cascade through to other subsystems of Finale's graphical output. Also, since they now fixed the PS problems on Windows (at least on WinXP -- I just can't understand why a fix for WinXP would fail to work on Win2K), at least Windows users who require better onscreen rendering now have the compile-to-PS option. That is exactly the kind of situation where I as a programmer would treat such a feature request as low priority -- if very few people are truly bothered by it, and if the people who are have a viable workaround for the problem. That doesn't mean I wouldn't like it fixed. It just means that I can conceive of good reasons why it hasn't been fixed. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
On 24.09.2007 Dennis Bathory-Kitsz wrote: As I say, the only thing Finale's Compile Postscript Listing doesn't do is compile the TIFF graphics with it. Have you tried using EPS graphics instead? Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
Since PDFs are basically postscript, and Finale's display, I guess, is also a kind of postscript, this should be solved easily. This does not address the fact that Finale's Compile Postscript Listing function produces a perfect display. Finale prints to Postscript and compiles Postscript quite differently. Just look at the Postscript listings themselves. They're different almost immediately -- and it doesn't matter which Postscript driver is used. I've been through dozens because I have many installed for different print jobs. I also have Distiller, Ghostscript and docPrint Pro. The same results occur with those -- great results from Compile Postscript Listing and terrible from printing to Postscript. The example you posted looks like the quality display produced by Compile Postscript Listing rather than print-to-Postscript. What was your printing sequence from Finale? And what printer driver were you printing to? Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
PS to previous: The reason this is very important for me is that Compile Postscript Listing does *not* include embedded graphics. For many scores, I need them, and have had to fall back on printing to Postscript and its poor results. Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
On 23.09.2007 [EMAIL PROTECTED] wrote: The example you posted looks like the quality display produced by Compile Postscript Listing rather than print-to-Postscript. What was your printing sequence from Finale? And what printer driver were you printing to? No, he just used very thin lines. If you print this example it will look pretty awful, at least to my eyes. If you look at the example at high magnification you will still see that the lines don't anti-alias, and display slightly different thicknesses. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
Johannes wrote: No, he just used very thin lines. If you print this example it will look pretty awful, at least to my eyes. If you look at the example at high magnification you will still see that the lines don't anti-alias, and display slightly different thicknesses. The lines are very thin, but showing identical thicknesses here. I enlarged to 6400% on Acrobat Reader 8 with no issues. And the curves (which are normally disasters in print-to-Postscript displays) also show as curves, not at all jagged. The beams are not showing up as multiple lines at any magnification, which is a characteristic of print-to-Postscript under Windows. And the file size is very small. Now if I can see one of these with embedded graphics :) Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
On 23 Sep 2007 at 21:37, Kurt Gnos wrote: Since PDFs are basically postscript, and Finale's display, I guess, is also a kind of postscript, Huh? How does Finale on Windows utilize PS onscreen? The fact is, it doesn't. For that matter, on Mac, display PS *is* used for rendering, but at the OS level, not in Finale itself. Finale takes its data file, translates it into what it wants painted onscreen, then hands that off to the OS, which then renders it using display PS. On Windows, of course, no PS is involved in the display at all (except maybe the fonts). this should be solved easily. It's the same issue we've been discussion with the XML converter -- Finale converts its data file to its internal represention of what should appear onscreen and then hands it off to the OS to render. That means there's a conversion/translation operation, so that's where problems can creep in. Finale is drawing the lines onscreen in a way that Acrobat Reader doesn't render well. To me, the problem is with Acrobat, not with Finale, though the ubiquity of Acrobat should give Finale's developers pause in rendering their lines as multiple lines, instead of in the more usual vector-based approach (i.e., describe the line by its width and thickness, rather than drawing multiple skinny lines to get a thick line). -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
On 23 Sep 2007 at 15:46, [EMAIL PROTECTED] wrote: Since PDFs are basically postscript, and Finale's display, I guess, is also a kind of postscript, this should be solved easily. This does not address the fact that Finale's Compile Postscript Listing function produces a perfect display. Finale prints to Postscript and compiles Postscript quite differently. This is perfectly explainable. On Windows, there is the native graphics/printing subsystem, which has zilch to do with PostScript. On Windows, Finale outputs using the Windows graphics/printing subsystem's primitives, which are then translated by a specific printer driver into that printer's output language. So, on Windows when printing to a PDF driver, Finale is sending *Windows* commands that are then translated by the driver into PostScript. When you compile a PS listing, Finale is doing the conversion, rather than letting the PDF driver do it, and Finale probably sends different commands to its internal PS interpreter than it would send to the Windows universal print driver. On Mac, there is no issue of this kind, as the Mac universal print driver is built on top of PostScript in the first place, so the same Finale primitive output could drive both compiling to PS and printing to a PDF driver. But, again, the problem as I see it is *not* with Finale, but with Acrobat's incorrect line smoothing. I don't know why Finale sends multiple thin lines instead of a single line with a particular thickness to the print driver, but perhaps there's a reason for that. I fear, though, that the reason is that this is a holdover from pre- TrueType days (i.e., circa Finale 2.01). I can't imagine that any modern printer or display could not properly render a line that was defined as a single line with a thickness instead of as a bunch of thing lines bunched together to make a thick line. But I don't know the details. Perhaps it's much more complicated than it looks and that's why MM has not changed the way Finale on Windows outputs lines to the universal printer driver. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: AW: AW: [Finale] Converting from Sibelius to Finale
On 23 Sep 2007 at 22:09, Johannes Gebauer wrote: On 23.09.2007 [EMAIL PROTECTED] wrote: The example you posted looks like the quality display produced by Compile Postscript Listing rather than print-to-Postscript. What was your printing sequence from Finale? And what printer driver were you printing to? No, he just used very thin lines. If you print this example it will look pretty awful, at least to my eyes. If you look at the example at high magnification you will still see that the lines don't anti-alias, and display slightly different thicknesses. Huh? Viewed in what software? When I look at the example at 100% and 2400% (or any other magnification I choose) in Acrobat Reader 8 none of the staff lines are aliased. NONE. True, it will not print well, but if you're producing your PDF for online use, this seems like a good solution to me. It also discourages people from printing it and using it. But no, it's not a good solution for PDFs that are intended to be printed. Of course, this just shows the inherent conflict at the heart of all PDFs: The requirements of onscreen and printed output are often in severe conflict with each other. I have always felt that PDF works much better for printed output than for onscreen display (fonts for print are usually too small in relation to page size for ease of use on a screen, unless you have one of those portrait-mode monitors). This is the same problem I always had with the Sibelius page display for editing (which has been eliminated as a problem in Sib5), that what I needed to see all at once was the whole page, or just the part I was editing, and moving from system to system caused it to jump around. And viewing a full page at a time everything was too small. Anyway, I'm just blathering now, so I'll stop! :) -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
