Print layout engine for Linux. Fully ICC aware

[riclin]

Just for the sake of transparency... This was all done with AI. Claude Opus for the heavy lifting and an open source au model for the coding.

I don't know how to code but I know about operating systems work in general (I'm a systems administrator) and know the color managed printing path on Linux quite well.

There is about 50 hours of work involved on a project like this and probably as many pages of copy paper in the recycling bin. The initial code produced by Claude had gotten so many things wrong because it thought it knew what it was doing.

I still really enjoyed the experience. It's like having a junior programmer that does a lot of mistakes. In a few cases, when mistakes were made I realized I needed to give the AI more info to begin with

Very impressive results - compiled up cleanly and does what it says on the box. Congratulations! - we've moved into a new era of code development eh? A suggestion on behalf of potential users outside the US - perhaps you might consider incorporating metric measurements as an alternative (or addition) to imperial units for image sizes? - although you already allow for metric "A" paper sizes, the image sizes are all in inches - mm or fractional cm would make a lot more sense when working with metric papers. Otherwise - great effort!! Thanks.

r/

 

[crenedecotret]

Very impressive results - compiled up cleanly and does what it says on the box. Congratulations! - we've moved into a new era of code development eh? A suggestion on behalf of potential users outside the US - perhaps you might consider incorporating metric measurements as an alternative (or addition) to imperial units for image sizes? - although you already allow for metric "A" paper sizes, the image sizes are all in inches - mm or fractional cm would make a lot more sense when working with metric papers. Otherwise - great effort!! Thanks.

r/

Thanks for trying it out I think we are soon entering an era where people will need to think about how things work but not necessarilly need to worry about the code itself.

The "A" sizes was on my to do list but I wanted to get all the basic functionality out of the way first. That should be very easy. There is probably some other areas where I would need to switch to metric.. border calculations for example where right now i'm using the point system.

I probably also need to think of a way to package this to DEB, RPM or flathub but I have no idea where to start.

Just out of curiosity, what printer did you try it on? I only had a few available to me at home and at work but the printer properties detection code was difficult to set up

 

[riclin]

Thanks for trying it out I think we are soon entering an era where people will need to think about how things work but not necessarilly need to worry about the code itself.

The "A" sizes was on my to do list but I wanted to get all the basic functionality out of the way first. That should be very easy. There is probably some other areas where I would need to switch to metric.. border calculations for example where right now i'm using the point system.

I probably also need to think of a way to package this to DEB, RPM or flathub but I have no idea where to start.

Just out of curiosity, what printer did you try it on? I only had a few available to me at home and at work but the printer properties detection code was difficult to set up

I don't see a problem with specifying borders in points - but setting image sizes in inches just feels clunky - sorry . Millimetres or fractional centimetres feel more appropriate when laying out several smaller images to fit a single page size - but perhaps that's just me!

I printed with both a Canon IP8700 and a Pro-10S - Vibeprint found them both as well as every other printer instance on my net. I should add that I use TurboPrint instead of pure CUPS but I don't see that as being of much importance - it also found all of my CUPS printer instances even though I didn't actually print to any of them.

So far as packaging - well I guess that depends on whether you intend distributing source or only the binary. If the latter, then I'd suggest a deb (or similar). If you're just distributing the source, then a compressed tar file makes sense (vibeprint.tar.gz) - and if you intend continuing down the OSS path then you'll need a package for the code anyway. Personally, I'm not a fan of flatpacks because of the likely duplication of libs etc - YMMV.

But all up - a good thing. You've briefed Claude well. Congrats!

r/

 

[edmundronald]

What 8550 driver is available?

 

[ThrillaMozilla]

It's sort of a "base" margin that's all around the paper. I noticed most printers will have something built in. On windows my R2000 was 3mm unless it was set to borderless. On linux it defaulted to 0mm. The option is there basically to fix any driver inconsistencies. By default it will read what CUPS reports but the user can define a larger value if they want to be on the safe side.

Say you want to print 12x18 on 13x19 paper. There would be two ways to do it.. you either leave the paper as detected and select 12x18 photo size when you add it to the canvas... OR you add a 1 inch border to your 13x19 paper and select the "Fit to page" option for the image

Thanks, but the margins were taken from Epson Print Layout on Windows, and that works, so I know the margins are right. I can also define larger margins and it still doesn't print. The error could be anywhere, and I have many things to do before I try to find the problem. It may even get fixed when I finally update my Linux system.

 

[ThrillaMozilla]

I don't see a problem with specifying borders in points - but setting image sizes in inches just feels clunky -

But the paper is in inches, so we need the option. 10.75" is no more clunky than 26.0 cm or whatever.

 

[riclin]

But the paper is in inches, so we need the option. 10.75" is no more clunky than 26.0 cm or whatever.

Without checking the code, I'm guessing that paper sizes are not hard coded but are being pulled from printer properties? - because I'm seeing a bunch of options including A paper sizes in the properties box next to the printer name so I'm guessing that the paper sizes are already being served up by the printer driver. As far as dimensional units are concerned - it's probably in part what one is used to, but the US is one of the few countries still using imperial measurements. Almost everywhere else uses the metric system - and having to mentally convert from mm or cm back into inches just seems - well I've got to say it - clunky!

EDIT: - just checked in case I was mistaken - there are only 3 countries officially using the imperial system - Liberia, Myanmar and the USA.

 

[crenedecotret]

Without checking the code, I'm guessing that paper sizes are not hard coded but are being pulled from printer properties? - because I'm seeing a bunch of options including A paper sizes in the properties box next to the printer name so I'm guessing that the paper sizes are already being served up by the printer driver. As far as dimensional units are concerned - it's probably in part what one is used to, but the US is one of the few countries still using imperial measurements. Almost everywhere else uses the metric system - and having to mentally convert from mm or cm back into inches just seems - well I've got to say it - clunky!

EDIT: - just checked in case I was mistaken - there are only 3 countries officially using the imperial system - Liberia, Myanmar and the USA.

Paper sizes are indeed pulled from the driver but image sizes are hard coded. Should be no problem at all adding the "A" sizes. Having switch to go from imperial everywhere might be a bit more work.

I'm in Canada which is a bit of an oddball. We mostly use metric for everything except construction work. Paper sizes follow US standard.

 

[ThrillaMozilla]

Without checking the code, I'm guessing that paper sizes are not hard coded but are being pulled from printer properties? - because I'm seeing a bunch of options including A paper sizes in the properties box next to the printer name so I'm guessing that the paper sizes are already being served up by the printer driver. As far as dimensional units are concerned - it's probably in part what one is used to, but the US is one of the few countries still using imperial measurements. Almost everywhere else uses the metric system - and having to mentally convert from mm or cm back into inches just seems - well I've got to say it - clunky!

EDIT: - just checked in case I was mistaken - there are only 3 countries officially using the imperial system - Liberia, Myanmar and the USA.

If you download the Hahnemühle paper catalog in French, you will find SI sizes and sizes in inches. If you download the US catalog, you will find sizes only in inches. If I bought a 17" or 44" printer, I would buy paper and software to match. As it turns out, I have a 13" printer, and neither A3 nor B3 paper matches the size, and I don't want the much narrower A3. I assume the special size A3+ (almost 13"x19") was created just for us -- and for you too if you can use it. In the US almost all photo paper is sized in inches.

Like it or not, we're stuck with inches. I'm a scientist, so I have nothing against the SI, but some things are just in inches, and there's nothing we can do about it.

Paper sizes are indeed pulled from the driver but image sizes are hard coded. Should be no problem at all adding the "A" sizes. Having switch to go from imperial everywhere might be a bit more work.

I'm in Canada which is a bit of an oddball. We mostly use metric for everything except construction work. Paper sizes follow US standard.

Predefined paper sizes may well be pulled from the driver, but there is a very good reason why all print programs, including Epson Print Layout, allow custom sizes. Also, on my Epson ET-8550 I have to print 11"x17" on my Windows system but cannot print on my Linux system.

Hard-coded image sizes are for convenience only, since one can print at almost any size.