k...@aspodata.se writes: > David >> k...@aspodata.se writes:
> My point was: >> > Though, my conclusion was that pdf is not better than ps regarding >> > postprocessing, and yes I know that pdf (depending on pdf version) has >> > some features that ps don't have. >> >> But nobody is talking about PDF. > > You seem to have a short memory, from your initial message: > last time I looked at Cairo, its PDF generation was not really suitable > ... > We might also be able to forego creating PostScript as an intermediate > stage to creating PDF and create bitmap formats without using PostScript > as well (again, this should really speed up things). So where do you read _anything_ concerning PDF that has _anything_ to do with how LilyPond creates PostScript? You changed the topic to PostScript output, and PDF just does not factor into it. Neither did you state that you wanted to process LilyPond's PostScript output and _then_ convert to a bitmap or PDF. >> The difference in question is Cairo-generated PostScript vs the >> PostScript generated by Scheme programming and LilyPond's >> music-drawing-routines.ps and encodingdefs.ps . > > The Cairo-generated ps is much less readable than lilyponds. > > If you wanted to get rid of the lilyponds own generation of PS, I > offered my help to get it up to speed instead, but you didn't > understand that since: > >> >> "taking care of PostScript" is not related to converting LilyPond's >> >> graphics internals to Cairo since LilyPond's graphics internals are >> >> not written in PostScript. > > You are obviously not understanding my offer and your mind is set on > using cairo instead. I rather get the impression that you are not understanding your offer. The architectural problems with LilyPond's graphics processing have nothing to do with PostScript generation. It would make sense to delegate a lot of them to Cairo. When doing that, there is no point in _not_ using Cairo also for creating output, in particular since it will provide a number of efficient well-supported targets without extra effort and will write PDF and bitmap targets (and vector targets and X and GL targets, very useful for integrated surfaces like Frescobaldi) without needing to go through Ghostscript. I don't expect that the Cairo backend for PostScript and even PDF will start out competitive with what LilyPond has already: I expect a period where it will be used in parallel with the existing backends, just like the TeX backend existed for a while when LilyPond produced direct PostScript output. Now in particular font handling is a full-blown nuisance occupying several LilyPond developers. This will not likely change but move to the Cairo backend since the payoff for that work is quite higher (for example, we currently have defective font handling for the separate SVG backend). If you want to maintain a separate PostScript backend, this will include maintaining its font handling. Can you imagine how much work it would have been separately maintaining a TeX backend instead of removing it from LilyPond all those years of LilyPond 2? Basically you are stating that you want to do exactly that with the PostScript backend, and I am telling you that it will be more work than you likely realize. So you tell me I have no idea what I am talking about but don't bother to point out _any_ particulars where you consider my analysis faulty. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
