Quote:
Originally Posted by lilman
Can you post the names of the zip and rar files you used that resulted in a single pdf. I'm guessing they had the same auto sensed suffix.
|
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.
Quote:
Originally Posted by lilman
max_dpi is the maximum allowable dpi for output images. If an image has a dpi greater than max_dpi, it is processed to max_dpi; if an image has a dpi lower than max_dpi, no dpi processing is performed (since increasing an image's dpi uses pixel estimation, quality would be no better). max_dpi reflects the maximum dpi of the particular ereader you are processing manga for. Placing an image on an ereader with a dpi greater than the ereader screen can support does not make the image look any better, and at the same time dpi directly relates to file size so you are wasting file space without any gain in quality.
|
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.
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.
Quote:
Originally Posted by lilman
ImageMagick processes each image individually, except for pdf creation. With pdf creation, ImageMagick has to deal with all of the images that will become part of the pdf at the same time. For larger pdfs (greater than 150 images) this can be a real resource hog, and can possibly even fail.
|
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.
Quote:
Originally Posted by lilman
Um, I'll have to think about that. Somebody else requested an option for adding borders to an image that is smaller than the specified size, I will probably go with that.
|
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.
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:
- Have a property file option to set trim limit in percentage. 100% would be the current setting of no limit. Maybe 5%?
- Translate percentage limit to pixel based on the original image dimensions.
- 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.
- Determine which sides (top/bottom, left/right) has the smaller border (width of background pixels to closest page element)
- Resample oversized image so the smallest border sides side is at the target resolution.
- If the larger border sides is still over the target resolution, trim background until it is.
- If image is still oversized, resample to the target resolution.
- Fill in border.
I hope that made sense. It seems to work (in my mind)
.