Hi Mica,

Am 19.11.2013 um 22:39 schrieb Mica Semrick <paperdig...@gmail.com>:

> Keith,
> 
> Maybe you should explore an XML format that can be transformed directly to 
> epub. You'd also be able to write a style sheet with ConTeXt that would out 
> put a PDF as well. I think TEI-Lite is a good starting point.
        While XML is one approach and using XML-Styles and DocBook I could even 
do without ConTeXt completely. Yet, from a general
        user standpoint this way of marking up ebooks is tedious. XML has 
become the standard for storing all kinds of data. A a storage
        format it is great and allows for conversion to other formats for ages 
to come. YET, one has to know what XML is how to use it
        how to make tools to process it. That is something that I would not 
like to enforce on the average author. 
> 
> Since you can make your own commands in ConTeXt, it will never be able to 
> intelligently map all commands on to simple HTML.
        How true. That is the problem with any system that is and can handle 
more complex structures than a simpler system.
        That is why any module geared to creating ebooks has to only allow what 
is needed and can be done in any EREADER, 
        (notice I wrote reader not / Book or EPub!)

        My Idea is to use the Lua capabilities of ConTeXt to get the job done.
        I will try to exemplify.

        suggest MWE:
        \usemodule[ebook]

        \setupcss[…]{…}% see comment #1
        
        \setupmapping[…]{…} % used for when author has his/her own ideas #2

        %normal ConTeXt sets see comment #3

        % possibly set a mode or set externally
        
        \starttext
                \startebook
                        \chapter… %see comment #4
                                \startparagraph{leftmargin=20%, …] % see 
comment #5
                                % text
                                \stopparagraph
                                \starttable…
                                \stoptable
                                …
                \stopebook
        \stoptext

OK, this pretty much looks like standard ConTeXt
Comments:
        1) Here is where the author can define the CSS he wants
            It will integrated into the CSS used for the ebook

        2) The author can setup how the ebook commands are mapped to
             ConTeXt commands

        3) Here are setups for the  NORMAL ConTeXt commands for producing PDFs

        4)  if mode is PDF command is mapped to normal ConTeXt injected into 
stream
             if mode ebook, gather information for spine, etc, start a new file 
for the chapter
             start writing to this file as HTML 

        5)  if in mode PDF map to ConTeXt command, whereby the leftmargin is 
used as the
             basis for the calculation .2\textwidth or if you wish

This approach is ebook centric. Allows for rapid prototyping and proofing of 
the ebook using a PDF
This approach alleviates the need to attempt to dumb down ConTeXt markup. 
Through the use mappings te author has the possibility of producing a higher 
quality PDF if wanted.
The system could be designed to produce a file with the ConTeXt commands that 
can be edited for even
higher quality PDFs of printed versions. 

There could be even XML or whatever mode in the ebook module.

Another advantage would be is that we are a module that will produce HTML out 
of a ConTeXt styled syntax
that can be directly converted to a PDF directly, without worrying about lose 
of formatting or using tools over
which features are supported or not. This is a straight forward approach.

True, enough, ConTeXt is not designed to be a  HTML editor. 

It is a matter of design policy! The philosophy of going from TeX/ConTeXt 
centric to HTML is IMHO far inferior than
going from HTML/ebook centric to ConTeXt. One can always make things more 
intricate/complicated and taking something
complicated and morphing onto a less sophisticated system.

What one has to keep in mind is that ConTeXt "renders" to PDF and that is what 
is not needed when producing a ebook.
The rendering is done by the ereader. ConTeXt does have any information about 
screen size or  orientation. ConTeXt is built upon 
a page morphology. ebooks are not! So any decent approach has to keep this in 
mind.

regards
        Keith.

> 
> 
> On Mon, Nov 18, 2013 at 10:12 AM, Keith J. Schultz <schul...@uni-trier.de> 
> wrote:
> 
> Am 18.11.2013 um 16:33 schrieb Hans Hagen <pra...@wxs.nl>:
> 
>> On 11/18/2013 4:11 PM, Keith J. Schultz wrote:
>>> Hi Hans,
>>> 
>>> 
>>> Am 18.11.2013 um 13:21 schrieb Hans Hagen <pra...@wxs.nl>:
>>> 
>>>> On 11/18/2013 10:00 AM, Keith J. Schultz wrote:
>>>> 
>>>>>   2) Now, what a EPub-READER must implement to handle is very
>>>>>        little. There are HARDLY ANY provisions that a certified 
>>>>> EPuB-READER has
>>>>>              to implement any particular engine or features therein to 
>>>>> display/render
>>>>>        the information contain in the EPub-file/wrapper.
>>>> 
>>>> right, and I'm not going to waste time on it till i have a decent ebook 
>>>> reader that behaves well
>>>     The point you are missing is that the ereaders are behaving well. They 
>>> are following the epub
>>>          standard, and that to the letter of the standard. The problem is 
>>> that the standard does not
>>>     enforce any particular implementation. If you look at the slow progress 
>>> of the standard that
>>>     actually requires a full implementation of the HTML5 standard. That  
>>> wait will very long.
>> 
>> sure, and every time i see an epub novel i realize that for something like 
>> that one really can stick to rather dumb html ... the point is that one 
>> cannot expect context to output simple everywhere accepted html from complex 
>> rendered input ...
>       
> I agree fully. But, Since there are those that wish to produce epubs aka 
> ebooks, they should not be doing complex
>       layout. One can always go from simple to complicated in needed, if 
> there were commands dedicated to epub/ebooks/html.
>       As I had pointed out in my last post below.
> 
>> 
>>>     Furthermore, ereaders are made by companies more interested in profits 
>>> than spending a few Euros
>>>     more to put decent HTML engines into their readers. Why they do not do 
>>> that is beyond me!
>>>> 
>>>>>> 3. Modify the way in which ConTeXt generates the XML files. Ideally, I 
>>>>>> should be able to write something like
>>>>>   Would be nice if there where commands in ConTeXt or a module for 
>>>>> defining what should go into the CSS and a
>>>>>   mode "epub" where the ConTeXt commands are converted to suitible HTML5 
>>>>> structures that are suitiable for
>>>>>   most ereaders.
>>>>>           Features:
>>>>>                        1) margins in percentages
>>>>>                        2) font sizes based on em
>>>>>                  3) a new file for every chapter optional for sections 
>>>>> user defined
>>>>>   Just a few. Lots more can be found in any decent documentation on 
>>>>> writing ebooks.
>>>> 
>>>> context outputs xml and as a bonus provides a css too ... one can always 
>>>> convert that xml to his/her ebooks liking .. maybe at some point the 
>>>> mtx-epub script will do that
>>> 
>>>     I always to like to look at programming as modular and would think that 
>>> a epub/ebook module would be nice that maps
>>>     there are commands for layingout ebooks. these commands can then be 
>>> mapped back to standard context commands.
>> 
>> in that case code in xml and either processit by context or transform it 
>> into something ebooks can render
>> 
>>>     For some interested in producing a epub then can use the conventions 
>>> for producing ebooks and ConTeXt can provide the
>>>     math conversions to regular page dimensions used in PDFs for proofing 
>>> or creating a printed version. It would also make the
>>>     creation of EPubs from ConTeXt a simple parsing exercise.
>> 
>> so far i had no projects where epub was needes so it has a low priority and 
>> i still read paper books (or when i would have ebooks i wouldn't need to 
>> render them) ... pdfs views quite well on e.g. nexus 7 devices and i assume 
>> the upcoming sony high res ebook will also do pdf well
> 
>       Well I did start the discussion. Just offer my 2 Euro cents worth. 
> Especially, since it comes up every now and then.
>       Furthermore, I there was a simple way to create epubs/books with 
> ConTeXt more would use this feature. 
>       
>       I have used up enough of or time.
> 
> regards
>       Keith.
> 
> 
> 
> ___________________________________________________________________________________
> If your question is of interest to others as well, please add an entry to the 
> Wiki!
> 
> maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
> archive  : http://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________
> 
> ___________________________________________________________________________________
> If your question is of interest to others as well, please add an entry to the 
> Wiki!
> 
> maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
> archive  : http://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Reply via email to