[Sugar-devel] about reader

[Lucian Branescu]

On 29 September 2010 14:08, Gabriel Eirea <geirea at gmail.com> wrote:
> Hi:
>
> I'm replying to the list for more feedback. Please see below.
>
> 2010/9/29 Lucian Branescu <lucian.branescu at gmail.com>:
>> On 29 September 2010 13:24, Gabriel Eirea <geirea at gmail.com> wrote:
>>> Hi Lucian:
>>>
>>> I've seen you are actively working on the Read activity. I am from
>>> ceibalJAM in Uruguay and we have a request for certain features and I
>>> would like to know your opinion about them. We may find a volunteer
>>> here to work on them, and maybe we can get some funding but it's still
>>> a remote possibility.
>>>
>>> The request comes from an editor that donated an ebook in pdf for
>>> Ceibal and finds it difficult to read in the current version of Read.
>>
>> Hi.
>>
>> I'm not a Read maintainer, I just lent a hand to fix Read temporarily.
>> I'm one of the maintainers of Browse, so my priorities are there. I
>> don't mean to discourage you from asking me things about Read and I
>> still intend to help out with Read if I find the time, I just wanted
>> you to know my position.
>>
>> You should also post this to the mailing list, others may have
>> better ideas than me. You can just add the mailing list email to the
>> CC when you reply.
>
> OK, thank you Lucian.
>
>>>
>>> The requested features are:
>>>
>>> - possibility to include a floating menu for navigation
>>
>> No other activity has done this before afaik and I'm not sure the
>> Sugar UI guidelines. I also don't know how resource intensive this
>> would be, but it may slow down scrolling. I believe keyboard
>> shortcuts, the XO game buttons and locking the navigation toolbar are
>> better solutions (the latter can already be done by clicking the
>> navigation toolbar button).
>
> Apparently this is a pdf feature that has been used before by the
> editors of this book before. The idea is to have a button for the
> index, the main sections, etc. always visible on top or bottom.

As I said, right now you can click the button for the navigation
toolbar and the toolbar will no longer hide when you move the pointer
away. Is that acceptable?

>>> - possibility to call one pdf file from inside another
>>
>> You mean URLs to other PDFs? The way this might work would be to
>> download the PDF from that URL to the Journal and offer the user the
>> option to open it from the Journal (in Read). As of right now, the
>> Read activity has no internet access and I don't know if it's a good
>> idea to add this feature. Others may be able to say more on this
>
> This feature would be needed to speed up the loading of
> graphics-intensive books. I imagine there would be a bundle with
> several pdf files that would have links among them. I don't know how
> to make this compatible with the journal.

I think would be better achieved with a single PDF or a single EPUB
file. To open multiple PDFs anyway, Read might be able to open a .zip
file and open PDFs/EPUBs from there, but again I'm not sure it's a
good idea r.e. UI guidelines.

>>> - possibility to call a web page from inside the pdf
>>
>> This scenario has been discussed before, with no useful conclusion.
>> The way security works in Sugar, activities are not allowed to open
>> other activities. An exception could possibly made for the browser or
>> the Sugar API could be extended so that activities declare what URIs
>> they accept to open (e.g. http:, file:, apt: magnet:, etc.)
>
> Apparently this would be a very useful feature for learning ebooks,
> since they would like to have links to webpages with further
> information on certain topics.

This feature needs more discussion - both UI design and implementation-wise.
At the moment, users can copy links and paste them in Browse.

>>> - add zoom by paragraph to improve legibility with small fonts
>>
>> Do you mean automatically zooming on a certain paragraph? I don't know
>> if evince (the backend we use for displaying PDFs) is capable of this,
>> I'd have to check.
>
> Yes, "automatically zooming" would mean for example using the
> navigation keys to select next/previous paragraph and showing the
> selected paragraph with a larger font.

I see. If evince has support for this, it won't be too hard to
implement. If not, it might be quite hard.

>>> - possibility to have different page sizes inside a document
>>
>> Do you mean pages of different sizes? How would these sizes be
>> determined? Do you mean zooming pages independantly?
>
> The page sizes would be defined at the time of creating the pdf. In
> this particular case they designed topics consisting of one
> illustration and a bunch of text, each topic uses one to two pages in
> the paper book, they would like to convert this so that every topic is
> one page in the ebook, of variable length so as to include the
> illustration and all the text with no blank space at the end.

I believe this is between them and their PDF creation software. Afaik,
PDFs with variable size pages should just work in Read.

>>> - adapt the xo buttons next to the screen to enable navigation using
>>> the floating menu
>>
>> Yes, it's possible and relatively easyto add both keyboard shortcuts and use
>> the XO buttons for navigation, regardless of the existence of a
>> floating menu.
>
> Thank you!
>
> Gabriel
>
>>>
>>> Do you think these features are possible using the current code base
>>> of Read? How much effort do you think it would take to implement them?
>>>
>>> Thank you,
>>>
>>> Gabriel