Table-like block with dotted lines

[Doitsu]

While we're at the topic, you can also use pseudo selectors to generate dot leaders.
However, this method will only work with epub3 apps and readers, e.g. iBooks or ADE 4.5/RMSDK 12.5 (or higher).

[JSWolf]

Is there a solution that will work with ADE 2.0.1? If not, then there is no workable solution for that specific format because it won't work on most Readers/apps.

[Turtle91]

Originally Posted by JSWolf

Is there a solution that will work with ADE 2.0.1? If not, then there is no workable solution for that specific format because it won't work on most Readers/apps.

Perhaps you are referring to post #7??

If you can't use current coding techniques because you want it backwards ...(compatible) and you don't want to take all the effort to do it manually, then simply code it without the dots.....

[Tex2002ans]

Originally Posted by Chris Jones

I'm putting together an epub where I need something that looks like the following [...]

1 - in col. 1 the nature of the "ingredient" padded by dots on the right using up the remainder of the cell.

2 - in col. 2 the corresponding quantity of the ingredient in ounces, quarts, etc.

The dots are called "dot leaders" or "dot fills". That may also help you search for other solutions (although I don't believe any of these would work in actual EPUB readers).

Originally Posted by GrannyGrump

You might consider using <dl> definition list ---- use your ingredient name as the <dt> "term" and the quantities as the <dd> "definition" --- definition is offset like a hanging indent. You can experiment a lot with the formatting.

I don't think you have to be married to a print-style layout, as long as the information is clearly displayed. Dot leaders are a sink-hole in reflowable epub, as you are discovering. Too many ways for the swamp to suck them down....]

I agree.

[Chris Jones]

[QUOTE=Turtle91;3568744]You can just use overflow and/or text-overflow with a very long set of periods to cover any eventuality such as:

[...]

/QUOTE]

I implemented your solution: simple and elegant… and since it works in Readium and the commonly used web browsers… being an optimist… I'll just cross fingers and hope these properties will eventually be generally supported by e-readers or tablets.

Now something interesting: I vaguely remembered that among a host of formats Kobo devices also support plain (non-epub'd..) HTML. I proceeded to run a test transferring one the html files in my ../OEBPS/Text directory to the Glo'… and the properties you recommended are recognized: the text is formatted exactly as it is in Chrome/Readium… etc.

Rather surprising that Kobo's software should be able to handle the rendering correctly with a single html file and be unable to do likewise when the exact same file is packaged as an epub don't you think…?

As an aside I remember someone in this thread wrote that he got this (?) to work after converting the epub to the kepub format. I tried likewise both by doing an EPUB->KEPUB conversion in Calibre and installing a Koboextended (?) plugin that does this automatically when you transfer the files to the device but I was never able to display the files on the Kobo… Caused the device to go blank and display a line of squares and presumably reboot…

Anyway… when I am done proofreading the epub I will just need to find some way to package the 30+ html files and the stylesheets in such a way that I can transfer everything to the Kobo device without too many headaches AND obviously without re-packaging everything to the .epub format. This would amount to using the Kobo's e-reading software as if it were a web browser… so to speak. I was thinking of perhaps creating an extra html file containing a simplified TOC with links to the different chapters of the book. Not ideal… but I can't think of a better way at this point.

Difficult to tell how I could best handle such an weird concept in a convenient way… I systematically use Calibre to manage my ~12,000 ebooks collection and would basically need to have the book contents in "plain html" form as a single separate entry in the Calibre library alongside the .epub version… be able to transfer it to the Kobo device just like any epub… and naturally have the Kobo device be able to manage it correctly… in other words open it for reading… create an entry for it in the "My Books" list so I can find it… NOT have to deal with 30+ different entries in my Kobo device's library… etc.

What I have found so far is that when I add simple html files Calibre automatically zips them together with a few automatically generated "epub style" files (mimetype, content.opf… etc.)… thus creating some kind of "pseudo epub's"… before it copies them to the Calibre Library… and correspondinly creates a database entry with the "ZIP" format. But I'm not sure if/how a multifile zip container and the single correponding database entry could somehow be created.

Is there anything in the Calibre documentation that might help figure out a practical strategy…?

Perhaps I should open a separate thread regarding these aspects…?

[davidfor]

Originally Posted by Chris Jones

Now something interesting: I vaguely remembered that among a host of formats Kobo devices also support plain (non-epub'd..) HTML. I proceeded to run a test transferring one the html files in my ../OEBPS/Text directory to the Glo'… and the properties you recommended are recognized: the text is formatted exactly as it is in Chrome/Readium… etc.

Rather surprising that Kobo's software should be able to handle the rendering correctly with a single html file and be unable to do likewise when the exact same file is packaged as an epub don't you think…?

The problem is that epubs are handled by the RMSDK. If that doesn't support something, then Kobo can't support it. Their kepub format is renderer is based ACCESS NetFront (though it might be Readium now), so it supports whatever that does. I have attached a screenshot taken on my Kobo Glo of the sample that I thought was posted in this thread converted to kepub. I don't know what is used for the HTML, but they use Webkit for the browser, so that's probably what being used.

As an aside I remember someone in this thread wrote that he got this (?) to work after converting the epub to the kepub format. I tried likewise both by doing an EPUB->KEPUB conversion in Calibre and installing a Koboextended (?) plugin that does this automatically when you transfer the files to the device but I was never able to display the files on the Kobo… Caused the device to go blank and display a line of squares and presumably reboot…

Is the book big or have a big ToC? If so, you probably hit a problem with the first time you open a larger or more complicated kepub. Usually they open OK after the restart.

Anyway… when I am done proofreading the epub I will just need to find some way to package the 30+ html files and the stylesheets in such a way that I can transfer everything to the Kobo device without too many headaches AND obviously without re-packaging everything to the .epub format. This would amount to using the Kobo's e-reading software as if it were a web browser… so to speak. I was thinking of perhaps creating an extra html file containing a simplified TOC with links to the different chapters of the book. Not ideal… but I can't think of a better way at this point.

Difficult to tell how I could best handle such an weird concept in a convenient way… I systematically use Calibre to manage my ~12,000 ebooks collection and would basically need to have the book contents in "plain html" form as a single separate entry in the Calibre library alongside the .epub version… be able to transfer it to the Kobo device just like any epub… and naturally have the Kobo device be able to manage it correctly… in other words open it for reading… create an entry for it in the "My Books" list so I can find it… NOT have to deal with 30+ different entries in my Kobo device's library… etc.

I don't know if that will work on the device. I don't know if a link to another HTML file will open the file. But, I don't remember anyone say it does or doesn't work. But, as stated above, the kepub will probably open the second time you try, so this shouldn't really be needed.

[Chris Jones]

Originally Posted by davidfor

The problem is that epubs are handled by the RMSDK. If that doesn't support something, then Kobo can't support it. Their kepub format is renderer is based ACCESS NetFront (though it might be Readium now), so it supports whatever that does. I have attached a screenshot taken on my Kobo Glo of the sample that I thought was posted in this thread converted to kepub. I don't know what is used for the HTML, but they use Webkit for the browser, so that's probably what being used.

How exactly did you convert your epub to kepub? I've tried different approaches and the kepub… result is always the same. The Kobo displays a blank page… waits a couple of seconds… flashes twice… and then I get the five black squares… presumably to let me know the application has crashed and it's rebooting. After what feels like perhaps one minute or so the Kobo displays the Home screen. If I try a second time etc. it takes me through the same motions.

Maybe I misunderstood something about how you're supposed to do the conversion via Calibre?

My understanding was that once the KoboExtendedTouch plugin was active the conversion was done on the fly while transferring the book… leaving the epub version in Calibre untouched and copying a kepub.epub version of the book to the device.

Is the book big or have a big ToC? If so, you probably hit a problem with the first time you open a larger or more complicated kepub. Usually they open OK after the restart.

What would be "big"? The file is 1.3M in size… the Adobe numbers tell me there are 1132 pages and as to the (nested) ToC it has three levels and approx. 800 nodes.

I don't know if that will work on the device. I don't know if a link to another HTML file will open the file. But, I don't remember anyone say it does or doesn't work. But, as stated above, the kepub will probably open the second time you try, so this shouldn't really be needed.

You were right about having doubts about this. Not only does it fail to recognize links to other files… but even links to another part of the same file do not work. I dumped my inline ToC entries right at the beginning or the <body> of the single file that contains the <style> definitions together with the html markup and the text and the inline table of contents does show up at the beginning of the book on the Kobo… with the letters in some shade of medium gray instead of black… but whatever I try with entries… press… long press… nothing happens. Of course I had verified in a web browser that my ToC entries were functional prior to transferring the book.

As a matter of fact support of text/html file appears to be… rather incomplete. Another example: I tried to do a search via the icon at the top right of the screen selecting "Current Read" in the pull-down menu of options and that does not do what you'd expect… It runs the search against… the Kobo User Manual instead…!

Yet another thing that does not work as expected is that the CSS classes I defined for first and second level titles specify "text-align:center" but this property is not correctly rendered. These titles show up either left-aligned or justified (left+right) with many spaces in between the words. Even though this works fine in Firefox, Chrome, or Readium…

I thought that perhaps Kobo's renderer found something wrong either with my classes or the html markup… and was just silently ignoring my definitions… Just in case… I ran the usual validation tools against my file and got no errors.

Anyway, if you can spare the time and give me step by step instructions on how you exactly do the kepub conversion… I'll give it one more try and move on.

Perhaps open a ticket with Kobo if that's at all possible..?

Thanks…!

[JSWolf]

Why would you use code that doesn't work in most real use cases?

[davidfor]

Originally Posted by Chris Jones

How exactly did you convert your epub to kepub? I've tried different approaches and the kepub… result is always the same. The Kobo displays a blank page… waits a couple of seconds… flashes twice… and then I get the five black squares… presumably to let me know the application has crashed and it's rebooting. After what feels like perhaps one minute or so the Kobo displays the Home screen. If I try a second time etc. it takes me through the same motions.

Maybe I misunderstood something about how you're supposed to do the conversion via Calibre?

My understanding was that once the KoboExtendedTouch plugin was active the conversion was done on the fly while transferring the book… leaving the epub version in Calibre untouched and copying a kepub.epub version of the book to the device.

No, you haven't misunderstood. The KoboExtendedTouch will do an on-the-fly conversion when you send the books. But, in this particular case, I just renamed the file. Changing the extension to ".kepub.epub" is enough for it to be treated as a kepub. And for a one or two page test case, or to do a quick check, it works well. But, if you are reading a book, you need the conversion so that the reading position and bookmarks are maintained properly.

What would be "big"? The file is 1.3M in size… the Adobe numbers tell me there are 1132 pages and as to the (nested) ToC it has three levels and approx. 800 nodes.

I would expect that to trigger the bug. The problem, I believe, is that when you first open a kepub, it does a word count for each ToC entry and stores it in the database. This is used as you read for the chapter graph in the in-book stats (my favourite thing about kepubs). But, this takes time and the bigger the ToC, the longer. But, there is a process watcher called sickel that will trigger a reboot if a process appears to be hung. What I believe is happening is that the word counting is taking to long and sickel triggers a reboot. For all my test cases, when I try to open the book again, it work. So I think that in the first attempt, enough of the counts have been done and stored that on the next attempt it finishes and the book opens.

I would suggest creating a smaller sample book with only a couple of chapters so you can see what it looks like.

You were right about having doubts about this. Not only does it fail to recognize links to other files… but even links to another part of the same file do not work. I dumped my inline ToC entries right at the beginning or the <body> of the single file that contains the <style> definitions together with the html markup and the text and the inline table of contents does show up at the beginning of the book on the Kobo… with the letters in some shade of medium gray instead of black… but whatever I try with entries… press… long press… nothing happens. Of course I had verified in a web browser that my ToC entries were functional prior to transferring the book.

As a matter of fact support of text/html file appears to be… rather incomplete. Another example: I tried to do a search via the icon at the top right of the screen selecting "Current Read" in the pull-down menu of options and that does not do what you'd expect… It runs the search against… the Kobo User Manual instead…!

Yet another thing that does not work as expected is that the CSS classes I defined for first and second level titles specify "text-align:center" but this property is not correctly rendered. These titles show up either left-aligned or justified (left+right) with many spaces in between the words. Even though this works fine in Firefox, Chrome, or Readium…

I thought that perhaps Kobo's renderer found something wrong either with my classes or the html markup… and was just silently ignoring my definitions… Just in case… I ran the usual validation tools against my file and got no errors.

It's been a long time since I tried a HTML file, so I just tried a couple. Firstly, they don't seem to like links to local other files. I tried a few things and none worked. A link to a web page will prompt you to open it in the browser. Not sure about the CSS. Other parts of the display suggest the HTML file is displayed using the kepub renderer. If so, it might only use the CSS that the kepub does. But, I'm surprised that anything you had in an epub didn't work here.

Anyway, if you can spare the time and give me step by step instructions on how you exactly do the kepub conversion… I'll give it one more try and move on.

Perhaps open a ticket with Kobo if that's at all possible..?

I always recommend reporting bugs and problems to the people responsible for them. There is link on Kobo's help page to report problems. As to how likely something is to happen, it really depends on how it fits with what they are doing. Some things get fixed quickly, others take a long time. But, if they don't know it's a problem for their users, they won't do anything.

[Chris Jones]

Originally Posted by davidfor

No, you haven't misunderstood. The KoboExtendedTouch will do an on-the-fly conversion when you send the books. But, in this particular case, I just renamed the file. Changing the extension to ".kepub.epub" is enough for it to be treated as a kepub. And for a one or two page test case, or to do a quick check, it works well. But, if you are reading a book, you need the conversion so that the reading position and bookmarks are maintained properly.

I would expect that to trigger the bug. The problem, I believe, is that when you first open a kepub, it does a word count for each ToC entry and stores it in the database. This is used as you read for the chapter graph in the in-book stats (my favourite thing about kepubs). But, this takes time and the bigger the ToC, the longer. But, there is a process watcher called sickel that will trigger a reboot if a process appears to be hung. What I believe is happening is that the word counting is taking to long and sickel triggers a reboot. For all my test cases, when I try to open the book again, it work. So I think that in the first attempt, enough of the counts have been done and stored that on the next attempt it finishes and the book opens.

I would suggest creating a smaller sample book with only a couple of chapters so you can see what it looks like.

It's been a long time since I tried a HTML file, so I just tried a couple. Firstly, they don't seem to like links to local other files. I tried a few things and none worked. A link to a web page will prompt you to open it in the browser. Not sure about the CSS. Other parts of the display suggest the HTML file is displayed using the kepub renderer. If so, it might only use the CSS that the kepub does. But, I'm surprised that anything you had in an epub didn't work here.

I always recommend reporting bugs and problems to the people responsible for them. There is link on Kobo's help page to report problems. As to how likely something is to happen, it really depends on how it fits with what they are doing. Some things get fixed quickly, others take a long time. But, if they don't know it's a problem for their users, they won't do anything.

I eventually found the time to run the test your last message implied…

1. I created a much smaller epub with the first of my html files. The toc.ncx and content.opf files were modified to reflect the change. Activated the "Kobo extended" plugin and transferred the book to the Kobo. I was able to open the converted book on the device.

2. I added the next four .html files from my original book, which entailed adding perhaps another twenty toc.ncx entries. I was again able to open the book… and I noticed that it was taking rather long… I also noticed that my nested ToC was there all right… complete with my second & third level entries… But since Kobo do not support nested tables of contents it had been "flattened" so-to-speak…

3. I proceeded to run a third test adding another five chapters from my book… This meant adding another 200+ entries to the ToC… This particular test version was now about one third of my original book and this sufficed to "successfully" recreate the problem: the Kobo crashed every time I tried to open the book… I did that maybe five times in all and consistently got the same result.

So it would appear that at least where sideloaded epub's as converted to kepub.epub by the "Kobo extended" plugin… Kobo's current software does not scale properly and cannot handle a table of contents with more than a few entries.

Apart from the fact that nested tables of contents are not supported… which makes large ones such as this particular book's all but useless--who wants to look for something sequentially in a ToC that spreads over a hundred pages especially on a device as slow as the Kobo Glo' I ask you… the fact that where kepub's and "raw" html are concerned, Kobo's e-reading software is unable to handle correctly titles that are marked "text-align:center"… I noticed another annoyance: I use em's to specify font-sizes and I rarely go beyond anything fancier than 1.3em… anything larger takes up too much space and looks rather gross to my sensitive eyes. And yet with this particular rendering software (as I roughly measured it) the font height and font width double in size when I go from 1em to 1.3em… whichever font I decide to use… This btw reminds me of something that I had noticed before on the sole book I ever bought from the Kobo store: titles that were unusually large giving the book the aspect of the ads on some cheap commercial internet site… something that I also notice on web pages as rendered in Google Chrome…

Well… considering that I don't feel it is worth having to jump through so many hoops hoping to miraculously get this to work… kind of… eventually… and find myself not happy with the result anyway… I'll put this on the back burner for the foreseeable future… perhaps have another look in 10 years' time… in case the situation has improved.

In any case… where I am concerned… this wasn't a waste of time… far from it… I now have a text version of the book almost ready to roll… and perhaps more importantly… the refresher course was worth every hour I spent… I try to "do an epub" once in a while so I don't forget my feeble epub skills for good.

Enough moaning and whining for now…

Thanks to all for your patience…