Hello Mike,

The auto roll length function is working almost perfectly for me when I specify both dimensions (custom -> enter specific size). The only problem is it returns a page size slightly longer than needed. If I turn the function off and select "set paper length" it shaves about a centimeter of excess.

When trying to use a custom size specifying only one dimension it fails almost every time and behaves erratically. When trying to place an image larger than the actual length sometimes it crops the image (with crop set to off), sometimes it shrinks the image to fit the paper. When placing multiple images sometimes it overstretches the paper leaving half of the page empty.

Printers tested: Canon Pro 4000 (regular driver and XPS), Canon IPF 8400
Windows 10 pro

I am out of the office now, but tomorrow I can send some screenshots and additional info if necessary.

Thanks again for this new feature, I am sure you will get it working 100% soon.

Hi Mike,

Probably my most anticipated feature. Unfortunately it is not working for me. Check what I get when I try to use it. Both standard Pro-4000 driver and XPS.
Additionally, the "set paper length (trim or fit)" option started returning the same message and it worked flawlessly until this version (used it today before the update). It also happens with the IPF8400.

Here is another small glitch on v122 (also on v121):

If you use additional margins to compensate for different top/bottom margins on cut sheets (i.e. adding a value to the top margin to make it equal to the bottom margin) it messes the manual placement of images making it impossible to move an image to the edge of the bottom margin.

Example:

Cut sheet on cut sheet on IPF8400 with two small images on the page, huge bottom margin, so I add to the top margin to make them equal (check the attached image). After that I want to freehand place the images to make them touch the bottom margin and the (adjusted) top margin. On the page editor I click on the top margin and use CTRL+up-arrow to move it to the uppermost position (works fine), then I click on the bottom image and use CTRL+down-arrow to move it to the bottom and it doesn't work. Actually it moves UP a bit. Dragging the image down does not work either.

If I move the image down BEFORE adding to the top margin it works as expected.

Fantastic features for us on the printing business (smarter placements and cuts) and also for the home user (the easy centering on cut sheets).
Thanks!

Thanks Mike!

This new roll feature is a great thing for us, professional printers. Just yesterday it saved me a few minutes of work and, more important, simplified a bit more our printing workflow.
I would also want to thank you and all the support team for the incredible work you do and wish you a happy new year.

Regards

Hello Mike,

Here is what I found so far:

(1) I can't make it happen again, but I am sure it wasn't the case of it reverting to B due to lack of space. There was plenty space left and the only way I managed to make it work was rotating the image previously on Photoshop so Qimage had no need to rotate it. Than it worked just fine, but even after that I managed to replicate the issue with the original file. I can't replicate it anymore because I uninstalled and reinstalled Qimage several times (108 to 104 and back to 108) and the problem disappeared.

(2) Some big images had the "image read error" on the thumbnail on my original installation of the 108 even after rebuilding the thumbs. Reverted to 104 and everything was fine. Went back to 108 and there was the "image read error" again on the same files.  But... when I made it rebuild the thumbs everything was fine again. I can't understand why the 108 was displaying "image read error" the second time before rebuilding the thumbs, but what matters is that it is working now.

I guess something was wrong with my first installation od 2017.108

Thanks for looking at it.

Hello Mike and everybody else.

I just found two bugs on 2017.108:

1) Canvas Mirrored borders using "B+" works fine as long as Qimage doesn't need to rotate the image to fit the paper. When it has to rotate the image it works like "B", including the border in the specified size instead of adding the border to the specified size. I am using metric system in case it matters.

2) Some big, high resolution files that I printed just fine with 2017.104 are no longer usable and display "Image Read Error" on the thumbnail. Reverting to 2017.104 solves the issue, reinstalling the 2017.108 the problem comes back again. A Tiff file with 14173x9411 pixels is the example I have at hand, but I noticed it with some smaller images (but bigger than 80mp).

Thanks.

Edit: The first bug (borders) is intermittent, sometimes it happens sometimes it doesn't, I am trying to identify a pattern but without success. The second bug about the high resolution files is constant.

Reading my post I noticed a small but crucial mistake that may have prevented the correct understanding of my point. This is what meant:


I hope it makes more sense now.

When I print on cut sheet paper (90% of the time I print on roll paper) I like to use the the "additional margin" to create equal margins on the four sides or at least symmetrical margins, compensating the uneven minimal margins. That way I know I can use "fit to page" with crop to get the largest print area possible with equal or symmetrical margins.
The only thing that annoys me is the fact that, while the minimal margins are displayed in gray on the live view, the additional are "invisible". I know they are there and it is not really a problem to me, but when I am showing the layout to a client before printing I always have to explain that.
I understand the reason why the minimal margins are displayed in gray and I also understand that we should have a visual difference between the minimal margins and the additional margins, but to me it would make mores sense if the minimal margins had a lighter gray. That way we would be able to see both margins and still differentiate between them. Alternatively it would also be nice to have print preview function that simulates the result without the gray margins and with the eventual crop marks, mirrored edges and so on.
Does it make sense to anyone else?

This bug is around since v2016.145 and is still present on v2016.146.

The border value changes and "sticks" to wrong values.
It may be relevant to add that I am using the metric system.

Example:
1) I click on the "zebra" button to ad an image to the queue specifying its size and borders (plenty of page space).
2) I select borders "B+" and click on border "1" and type 40 (40mm).
3) I click on "custom" to specify the image size and most of the time, but not always, even before I select any option or type any size, the border size typed on the properties window looses a zero (40 drops to 4).
4) If I hit OK the image goes to the queue with the wrong 4mm borders.

If I cancel and repeat it sometimes it works as expected, but it invariably reverts to the weird behavior lately.
I will attach some images.

Thanks.

It has been a while, but my memory says that is normal.

This notice pops up when you click on the option.
See screen snap.

Fred
[/quote]

How can that be normal? He clearly states the image size shrinks, not the page size as would be expected. I saw that happen a few times but is quite random on my system, 90% of the times it doesn't happen but sometimes it does. When it happens I usually quit the program and when I get back it usually works fine.

Oh, come on! 

I tested arrows, page up & down, ctrl arrows, alt arrows... Never occurred me to test + & -!
Thanks, my life just got easier.

A few years back, when I was getting used to Qimage Ultimate and deciding if I would use it or not, the automated job log + keyword search was the feature that sold it to me.
It saves me a lot of time and headache while reprinting and my job is basically to print limited and numbered series of large format artwork on demand. It is not unusual for a client to call after months asking me to run the next print of a series in a hurry because he made a sale of opportunity. Qimage makes this job a lot easier, I just perform a keyword search with the image name or the client/folder name and I am ready to print. I can't thank you enough for that.

But, with the intent of making things even easier I will suggest/ask a feature:
A "Next" button on the keyword search, so we could jump to the next match without scrolling.
Alternatively it could be implemented as a keyword "filter", only displaying the matching jobs.

The current search is great, but when we have a few matching jobs scattered under thousands of jobs it is easy to miss them while scrolling.

Thanks

I have noticed this problem in the past and "solved" it saving layered TIFF files instead of layered PSD files. Same functionality and never had a problem with TIFF.

Ok! That is what I thought. Thanks for confirming it.
Just sent the false positive notification.

Regards.