k...@aspodata.se (Karl Hammar) writes: > David: > ... >> Just tried it. Scaling the resulting graphic makes very clear that the >> import into odt did not happen as a scalable image, but merely as a >> bitmap. Anything else would have surprised me with EPS. > ... >> It is no longer vector graphics after that. > ... > > It might be just so that the oowriter gui that is not able to show the > eps correctly, since the saved file contains the same eps file as > produced by lilypond: > > $ unzip tt.odt > $ md5sum Pictures/20000002000001B8000000CDB9D1ED85.eps ../Imusic-1.eps > 023b4568290dc833c704f2a352eec342 > Pictures/20000002000001B8000000CDB9D1ED85.eps > 023b4568290dc833c704f2a352eec342 ../Imusic-1.eps > > and that is very much scalable. > > But then again, when I try to print it out, no graphics is printed out > just the text (entered directly into oowriter). I haven't worked much > with openoffice, but it doesn't seem to handle eps import correctly, > or have I missed something?
Judging from various message boards and the like, EPS import into OpenOffice is sketchy: For screen display and PDF export, it uses the preview bitmap. Ugh. If you print via CUPS, the EPS is used properly. It does not appear that OpenOffice could import any common vector graphics format reasonably. Changing that is not a priority either. People are told to just use fine enough bitmaps and be gone. This is stupid. I have workflows for TeX that are able to preserve vector data, and TeX is a dinosaur the OpenOffice users and programmers laugh at. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
