Comment 16 for bug 340203
Revision history for this message
| danh (danh-archive) wrote discussion summary, state modelled, scandata, status, deficiencies | #16 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
1. Discussion summary:
We had a meeting Monday (3/30) to decide how to scan right-to-left
books. Brewster, Matt, Robert, Eric, Raj, Hank, and i participated.
There were three proposals of how we could scan:
We had been pursuing the last of these using a design Hank
came up with and described in:
https:/
We had not yet modified republisher to be able to reshoot
spreads (the right-to-left mechanism scanned right-to-left
and right-side-up ends up grouping the images in pairs
offset-by-one from the way left-to-right right-side-up does).
To avoid doing this, the decision was made to scan
right-to-left books by going left-to-right
and upside-down, per Matt, as described in
https:/
Hank pointed out that one advantage of scanning right-side-up
is that it is natural and extensible. Scanners whose native
language is right-to-left and who are scanning works in
their own language may be able to work more easily
right-side-up.
Subsequently i had a private discussion with Steve who advised
trying not to seal off a general solution, and to keep enough
state around so that it would be possible to add another
scanning mode if the need arose. We also discussed what
state would be necessary to describe the scanning process,
as well as other related questions.
2. State Modelled:
We've attempted to leave hooks in suitable places in the
code to record these pieces of information:
(a) the page-progression (left-to-right or right-to-left)
(b) the direction of scanning (left-to-right or right-to-left)
(c) the vertical orientation (right-side-up or upside-down)
Note that (a) represents a property of the book alone,
while (b) is a property of the scanning process alone.
(c) is also a property of the scanning process, but to
determine whether a book has been scanned upside down
you have to know something about the book's contents.
We do not now actually use all of this state. Rather,
as soon as we detect that the page-progression is
right-to-left, we set (or rather, leave) the direction of
scanning as left-to-right and set the vertical orientation
to be upside-down. But hopefully we've left enough
hooks around that we can add another scanning scheme
as needed or desired.
On the scribe end this information is now basically handled only
by putting up an alert to the scanner that the material is
right-to-left and should be scanned upside-down---and
also writing out the scandata.
3. Scandata handling:
The scandata produced by the scribe for a right-to-left book
includes a fragment like
<
<
within the bookData (i.e., in /book/bookData, as opposed
to /book/scanLog or /book/pageData).
As described above, the first three parts of this are or
should be immutable after a book is scanned. The fourth
flag is necessary because in scanning upside down the
page data is mutated as described in
https:/
4. Status:
We've made all the changes described here and checked them
in. They haven't been tested except for some simple samples,
so we anticipate there will be sub-bugs to deal with.
The files changed and current versions are:
Scriblio.inc 1.49
scriblio.js 1.31
Scribe2.inc 1.8
5. Deficiencies:
There are at least two deficiencies that i am aware of.
One is that we can no longer scan in the right-to-left
direction. My justification is that i didn't have it
sufficiently controllable by flags to keep it in the
code base along with another scheme. This is sort of
unconvincing, but that's the situation. Hopefully
however we will be able to add it in if needed (although
it has been pointed out to me that the easiest time
to do something like this is as early as possible).
The second deficiency is that we transport information
about the page-progression (left-to-right or right-to-left)
through a separate means than we transmit other metadata
information.
This is bad for at least two reasons: it makes the code
more puzzling (why are there 2 mechanisms for transport?)
and it adds an additional point of failure (the new,
second means of transport).
We can fix this according to how bug
https:/
is resolved (Hank as added a comment to that bug
requesting that page-progression also be put in the
metadata table). Another recent bug report dealing with additions
to the metadata table is
https:/
and similar comments apply.
Thanks in advance for any correciton or clarification of any of
these points, or any further ideas about scanning right-to-left
books.