base file group other than OCR-D-IMG about browse-ocrd HOT 5 CLOSED

I hope I have fixed most of the points now, except the selectable file group, which is quite difficult to implement (but absolutely worth it) and now handled in #9

Why should the initial view be restricted to pages contained in OCR-D-IMG

The initial view file_group is now determined by the algorithm outlined in my comment, point 1., the (quite dirty) implementation is here

So how about presenting all structMap entries sorted by their @ORDER (if present) or @ID with the first fptr that shows up?

The page browser now uses all page_ids from ocrd_models.ocrd_mets.OcrdMets.physical_pages (but without taking @ORDER into account) to determine which pages "exist". It then tries to find matching image files from a given file_group to display. If no image is found for the page a "missing-image" icon is displayed.

from browse-ocrd.

That's a valid question, and I had the problem myself (original fileGrp not named OCR-D-IMG).
Solutions to your questions:

1. The fileGrp to display with PageListStore should not be hardcoded to OCR-D-IMG, but should be selectable like in ViewImages. As a default it should try:

• The first of a (configurable) list of preferred fileGroups to display as images ( OCR-D-IMG, MAX, ORIGINAL) which have a mime-type matching image/*.
• The first fileGroup (sorted by ???? maybe string length, because derived images usually have more complex name than the original?) which has a mime-type matching image/*.
• If there is no match according to the page_id in file_lookup-logic you described, display a "missing image"-icon

2. View.use_file_group is overridden in ViewXmland ViewImages. OCR-D-IMG is just the default value for all possible views. The use_file_group implementations in these views are actually quite robust and are taking the user selection and availability of the selected fileGrp into account. I think the way to go is to base PageListStore on the same implementation.

What do you think?

from browse-ocrd.

2: Oh, I see! Yes, sounds reasonable to base the initial view on that as well.

1: Yes, this would be very intuitive behaviour and easy to use IMHO. Or (instead of the second criterion) one could even start with an empty view if the first criterion (fixed/configured list of preferred groups) does not yield any images.

from browse-ocrd.

I hope I have fixed most of the points now, except the selectable file group, which is quite difficult to implement (but absolutely worth it) and now handled in #9

Great work!

The initial view file_group is now determined by the algorithm outlined in my comment, point 1., the (quite dirty) implementation is here

Wow, you even have a heuristic for the length of the candidate fileGrps in there!

The page browser now uses all page_ids from ocrd_models.ocrd_mets.OcrdMets.physical_pages (but without taking @ORDER into account) to determine which pages "exist". It then tries to find matching image files from a given file_group to display. If no image is found for the page a "missing-image" icon is displayed.

Works perfectly, many thanks!

from browse-ocrd.

I will close this now, for the rest see #9

from browse-ocrd.