[lilman]

Originally Posted by badbob001

It was something simple like:
"manga name z.zip"
"manga name r.rar"
I think the issue is that your app is really expecting "manga name 102" since you only use the "102" part. Since the files didn't have a number, I'm guessing your app dumps all numberless archives together. I'm guessing the use of the original file name option should resolve this.

What you have said is mostly correct. When using auto sense suffix on files that don't end with a number, it's not that Canti is dumping all numberless archives together, it just thinks that each of their suffixes is "" (i.e. empty string). Because they all have the same suffix, they all end up copying to the same folder in output_folder... or repeats get discarded, I don't remember how it works in the new brain. In any case, if you use auto sense suffix on files that don't end with a number, the output will probably be messed up; it is better to use use_original_filenames instead.

Btw, Canti can auto sense suffixes of the form [0-9]*[.]+[0-9]*[-]+[0-9]*[.]+[0-9]* (where * means 0 or infinte instances of what's in the brackets, + means 0 or 1 instances)
I think I wrote that regex correctly. The most complex case would be: 093.34-1234.234
Oh, and there can be spaces or underscores in between.
If you want to use auto sense suffix, you can rename your comics like "03a" and "03b" to "03.1" and "03.2". Or use use_original_filenames once it has been fixed.

Originally Posted by badbob001

How does a pixel image have dpi? It's just pixels and they have no physical size until it is displayed on a device. DPI is only relevant for vector elements, such as font text.

Dpi was a really confusing concept for me to understand (I had to read a few docs to get it). Dpi is the density of pixels in an image. An image with a high dpi means that there are many pixels occupying a small amount of space, and because of this, the image quality can be higher (since you are able to fit more color information into the same amount of space). Think about how the new iPhone4 screen is about the same physical size as the previous iPhone, but images on the newer iPhone can look so much better. This is because the newer screen has a higher dpi (well, there's other factors as well that make the new screen better, but the higher dpi is crucial).

Every ereader device has a certain dpi screen; for example, the Kindle DX screen has a dpi of 150. This means that every 150x150 pixel group takes up a square inch when displayed on the Kindle DX. Let's consider the different image dpi scenarios for a Kindle DX:
1) image has dpi < 150 (for example, 72)
If the image has a dpi of 72, then every square inch of the image is made up of 72x72 pixels. However, the Kindle DX screen displays 150x150 pixels per square inch. This means that each pixel of the input image must be interpreted larger than it was originally intended to. Thus, image quality is a bit lower.
2) image has dpi = 150
The image's dpi matches the screen's dpi. Every square inch of the image will correlate perfectly to a square inch on the screen, so image quality is perfect.
3) image has dpi > 150
The screen cannot handle having more than 150x150 pixels per square inch, so it must run an algorithm on the image at runtime to reinterpret each square inch as 150x150 pixels. There shouldn't be much quality loss decreasing dpi, but you are wasting file space since the screen isn't actually displaying all of the original pixels.

Does that make sense?

Originally Posted by badbob001

But if you're saying that PDF generation requires to know the physical aspects of the document (ie: height x width or dpi) so that 100% displays correctly, then I am fine with that. It's just too bad that this probably means 1 to 1 pixel display is near impossible when using PDFs. I'm guessing you're using the -density option in ImageMagick.

I don't have the Canti source code in front of me right now, but I think I use the -density option.

Originally Posted by badbob001

Maybe I just need to get more ram... I looked up seeing if ImageMagick supports combining several smaller PDFs together (convert *.pdf big.pdf) but reprocessing a PDF may degrade image quality. I suppose you could add an option to break up the volume every x number of pages.

I tried writing my own algorithm to break larger pdf projects into smaller pdfs and then join them all together... it didn't work any better than making one large pdf from the start. If the large pdf creation fails, doing it through smaller pdf merges also fails. The ideal solution would be for me to write my own pdf handler (I think the pdf standard is open source), but that's not going to happen since I'm already working on another project.

Originally Posted by badbob001

For undersized images, you should skip the cropping step for opposite sides (top/bottom, left/right) that are under the target resolution and just add borders. It doesn't make sense to crop and then add back the borders, which can shift the location of the page elements to the middle.

I was thinking about that. I still want to crop then add borders since I will include an option for the user to set border color (so you can trim white and then add back black border if you want, or vice versa).

Originally Posted by badbob001

For oversized images, yes it is tricky since you can't really know what are the true geometry of the original page. Maybe something like this can be done:

1. Have a property file option to set trim limit in percentage. 100% would be the current setting of no limit. Maybe 5%?
2. Translate percentage limit to pixel based on the original image dimensions.
3. Trim background pixels from all sides *equally* until a non-background is reached or pixel trim limit is reached or target resolution reached. This will help preserve the aspect ratio and keep image elements from shifting to the middle.
4. Determine which sides (top/bottom, left/right) has the smaller border (width of background pixels to closest page element)
5. Resample oversized image so the smallest border sides side is at the target resolution.
6. If the larger border sides is still over the target resolution, trim background until it is.
7. If image is still oversized, resample to the target resolution.
8. Fill in border.

I hope that made sense. It seems to work (in my mind) .

Using % with images is tricky because of dpi. This is made even more tricky since I think there are some images that you can't determine the dpi of (very annoying problem, it's the reason I use ImageMagick to determine dpi instead of letting Java handle it). I haven't programmed it yet, but I think I will keep the auto trim as it is and include the option to fill border for images smaller than the target size. That is the simplest way to go, and since I need to be focusing more on my new porject I can't spend too much time updating Canti.