[tkeo]

Hi Kevin,

If you don't like storing them in the mobi7 folder first then, I guess I don't understand why we can't simply write the files to a neutral location as we read them. Perhaps a base Images/ and HDImages/ and then in processMobiX put them in the proper location?

Also for the mobi 8 we want to create both an epub file and leave it unpacked in place so that users can see what is there more easily.

I prefer this approch.

Originally Posted by KevinH

Hi tkeo,
I looked at your patch from v067 to add epub3 support and your comments.

Firstly, the posted code is written with thinking, so it may be redundant.

- why do you want to move writing of files back to process_all_mobi_headers?
In general, an object should know how and where it should write itself. Therefore, NAV, OPF, NCX etc should all know where and how to create themselves from the passed in data and the "files" object.

In fact, my inclination is to move the writing of the text/html files out of even processMobiX and out to header specific routines.

I feel easier to understand what are extracted and built when calling of write() are placed in single function( or in single file). In addition, I prefer to avoid reading from written file during processing.

Another, I am considering to make an option to converting to epub only and output no other files. Holding datalist and partlist might be helpful to do so, but not necessary if there are other ways.

- you seem to duplicate information from k8proc to pull into k8resc. It would simply be easier to pass in the k8proc object is and where you need that information.

I will modify it; however, I am not fully understand your intention. Does it mean adding a parameter to K8RESCProcessor?

- your datalist[] simply duplicates much of what imgnames is used for and you never store any raw data in that list anyway. Why is the data offset information there if the data itself is never stored? Why do you need the section number? The directory and type information can easily be deduced from the file name extension, and metadata for (offsets).

As you mentioned, storing actual data makes memory usage lager; therefore secno and offset are stored to extract from sect, except fonts.

- why do we need to know the width and height of the images? Is this needed to create svg based cover pages?

Yes, it is needed to create the svg based cover page.

- Also do we really need to rename the cover image as "cover"?

It makes to find the cover image at a glance when looking in Image folder; but not crucial.

- Also Can't we simply use the EmptyImagePlaceholders and the kindleembed string from the "kind" section and info from CONT metadata to overwrite the the corresponding non-HD image file with the correct HDImage but keep its original name so nothing in the OPF needs to care.

The CONT and following sections up to the container boundary is a simple one-to-one mapping from the first image to the last HDImage with empty place holders being used to indicate images that do not have HD replacements (so they only need to keep track of things up to the last HDImage.

The number in image names are correspond to section numbers currently, so keeping the numbers might help to know where the image is come from; however, personally, I am not oppose to renaming (or write out) HD images to correspond to low resolution images.
It makes easer to switch the images in epub. I prefer to add an option to switch it by user.


For conclusion, I am not stick to the code I have written, but please consider and give feedback to me about adding an option to convert to epub only though I do not plan to this immediately.
And I would like to hear considerations from others too.


Thanks,
tkeo