Laidout / laidout

Laidout, desktop publishing software
GNU General Public License v3.0
80 stars 8 forks source link

Print/Export produce "weird" pdfs when a file is opened rather than a new project... #22

Closed JigmeDatse closed 3 years ago

JigmeDatse commented 3 years ago

If I create a project from scratch, the output from the "print" output.pdf ends up working as expected. I wanted to save some work with having to recreate the imposition, so saved it, and opened. I kept giving different tries with it, but it's ending up quite different than when I create it from scratch (which works well).

I have no idea where this difference might be, as it seems that the file I'm opening should work. I'm also not sure if I can provide any better information about what is going on.

The page orientation ends up incorrect, and the location of the imported images is not right either. It seems that there's a conflict happening with what the editor is trying to do, and what the print/export is thinking it should be doing.

I'm working with half page (one fold) letter, which the layout is in landscape, with a vertical fold.

tomlechner commented 3 years ago

Hmm.. if I understand, when you load in a file with the one fold imposition, it looks fine on screen, but orientation breaks only when you export to PDF? Is the page size correct, only orientation wrong? Do other exporters like svg work?

I probably won't have time to check this myself until the weekend, but I'll test when I can get a chance.

tomlechner commented 3 years ago

So far I'm not able to duplicate this. My steps:

They both produce the same results for me. Are these the steps you are doing? What version of Laidout are you using (hopefully the current development source or the AppImage)

JigmeDatse commented 3 years ago

I'm not sure if I'm not quite understanding your steps or not, but it looks pretty close.

I'm using the appimage, Laidout-7668589-x86_64.AppImage I have just downloaded the latest version (of about an hour old).

So this is the workflow I'm doing (writing as I'm doing it):

This workflow I think actually worked (ie. if I realized I needed to swap out a file, it did work, though I'm not certain...)

And with the 9 folio version it's not working.

With a single folio, I am getting it looking like the attached output-small.pdf

output-small.pdf

I hope that helps (I ran it through ps2pdf to get it smaller to upload).

tomlechner commented 3 years ago

Confirmed! Haven't had time to fix, but there's maybe a workaround.

I tried using the Export button (the button left of the printer), and it seemed to work, but doing it from the printer button fails. This is really weird because it should be using almost exactly the same code. Hopefully the workaround works for you?

JigmeDatse commented 3 years ago

Trying the latest version, which seems to have dropped the print icon. Currently trying to see if I can get output that works when opening a laidout file.

That is working brilliantly as best I can tell. Other than the confusion, I think that removing (unless there's some functionality that I haven't been using) the "print" works fairly well.

Did you have the option to run it straight to the printer? I can't do that from my main work computer right now, so I wouldn't use it.

Yes, there is the option to output to a command with the "print".

With the appimage 5bae477 the print does the unexpected output, and the export does the expected output.

Thank you so much for this.

tomlechner commented 3 years ago

Good!

Ideally, the Print button is supposed to make it easy to send things directly to a printer.

In reality, the Print button was just a hack to slightly streamline "export" to pdf, then send that to the "lp" command, but currently it barely provides anything over the export button, except headaches. I almost never used it. So, my plan with it is to merge the "send to command" option into the main export window, and to also make it easy to set up external commands, so you can send to any command, be it "lp" or "gimp" or whatever.

Someday perhaps I'll implement a real print dialog that lets you actually select a printer, but that's not going to be any time soon.. I usually print from either evince (for pdf) or inkscape (for svg), since they have real printer dialogs!

I'll keep this issue open to remind myself to work on this.

JigmeDatse commented 3 years ago

No problem. I know the software is quirky, but I don't really have a reasonable way to do this which wouldn't involve a lot of extra work. So, I'm happy with where it's at, and even more happy that it's in active development.

I very much am a person who doesn't mind using 5 tools for a single document, if that's a reasonable way to handle it. I am not that happy with software that does lots of stuff, but is either hard to figure out, or doesn't really do a good job of some of the things it's supposed to do.

tomlechner commented 3 years ago

So quick update, I implemented a way to define and save different types of executables, such as "lp" for "Print", or "Gimp" for "Image Editor", that can now be selected from the export window, so previous "send to command" functionality from the old "print" button still exists and is more useful and accessible.

The "Print" button itself is still disabled pending a real print dialog that deals with actual printers. Apparently I started to implement a PrintDialog (laxkit/lax/printdialog.cc) with libcups several years ago, but didn't get all that far. Since then the cups api ppd functions I was using are now deprecated, so that still needs a fair bit of work to actually be usable, but that can be another issue!