[badbob001]

My K3 hasn't arrived yet but I wanted to try out the latest Canti to provide feedback. I'm using this on Windows XP 32bit.

The component that deals with zip/cbz seems to be somehow faulty if the file contains folders within. resulting with:
java.io.FileNotFoundException.
(The system cannot find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at common.utils.FileUtils.unzipFile(FileUtils.java:51 9)
at manga.ConvertManga.main(ConvertManga.java:1314)

If I recompress the pages into a rar or a zip with no subfolders, then it works fine. It looks like when canti is processing a file, it extracts the content to a temp folder in the same place as the original file. When it processes a rar file with a subfolder, I see the subfolder within the temp folder. But when it processes a zip file with a subfolder, the temp folder contains a file with the same name as the subfolder, making me think the program is incorrectly trying to extract the subfolder as a file instead of a folder. Perhaps a quick workaround is to force the use of unrar to proccess zips.

While testing, I took the same set of pages and created a zip and a rar with different file names. After I ran canti against the parent folder, I was expecting it to result with two separate PDFs with the same content. Instead, I only got one PDF. Could it be that pages with the same filename will overwrite each other? I think it may be caused by the app putting every page under the same 'title'/folder. Perhaps once you get the 'use_original_filenames' option fixed, this conflict will be avoided.

What is the purpose of the max_dpi setting and what factors does it affect? We already know the input and output resolution, so dpi seems unnecessary. Is it perhaps relevant for PDF generation? With my output set to be 800x-1, displaying the PDF 100% shows the graphics expanded well over its 1:1 pixel resolution, which is wrong to me. Would changing the DPI setting affect the sharpness of PDF pages?

When processing a zip with about 250 images, my computer slowed to a crawl as convert.exe used more than 2GB of ram, most of which involved the page file since I only have 2GB of real ram. Is Image Magick trying to process all the files within memory at the same time? It may be less resource heavy to have Image Magick process pages in batches.

Can you limit the cropper to not crop the image to less than the specified output resolution? See attached 2-page spread as what can cause problems for Canti. I'm using 800x-1 so canti will only know the resolution for one side. Perhaps a hack like: 800x-600, which means that negative dimensions are ignored unless in special cases.

There is also an issue with pages that are smaller than the target resolution. One manga had an opening credit page that is originally 700x500. Canti rotated and cropped it and the resulting result was 306x445 (rotated). The sharp size reduction is due to the page being mostly black around the borders. The resulting image file looks fine but is a blurry mess when viewed from within the PDF, since the PDF viewer will automatically expand the page to fill the screen. For these small pages, perhaps you can use my previous idea to limit the crop and then use squall_dc's idea of filling in the borders to make the image meet the target resolution.

The readme file says in step 3: java -jar Canti.jar -create_device [device_name].
It should be: java -jar Canti.jar -create_properties [device_name].

Thanks!