Weird tables in epub

[RbnJrg]

Originally Posted by Psymon

Yeah, I understand that, but I guess there really isn't all that much alternative, is there? I mean, even if I didn't have that 3.2em margin at all, if it was just flush ("0") with no margins on either side, naturally the same sort of thing could happen if the user is going to increase the font size THAT big.

Hmmm, maybe not That is, if you set the font sizes of tables in "em", then you are right. But you can set the font sizes of tables in "px" and of that way when the user change font-size, tables won't be affected. So, a solution could be to set a left margin in "%" and the font-size of tables in "px". Of that way, no matter the font-size the user selects, tables will remain with the same look.

Thanks again, Rubén -- and I do appreciate your concerns, too!

You are welcome!

[Psymon]

Originally Posted by RbnJrg

Hmmm, maybe not That is, if you set the font sizes of tables in "em", then you are right. But you can set the font sizes of tables in "px" and of that way when the user change font-size, tables won't be affected. So, a solution could be to set a left margin in "%" and the font-size of tables in "px". Of that way, no matter the font-size the user selects, tables will remain with the same look.

Interesting thought -- although it brings to mind a couple of things. If you do that, then aren't you effectively defeating the whole point of allowing people to change the font sizes (re accessibility for people with poorer vision)?

Also, I don't really know alot about the "hardware" side of things, but with these newer hi-def tablets, how are "pixels" measured? Like, something that's 72dpi will come out like that, but are hi-def screens higher than that, and then wouldn't the text (and various other things) come out much smaller if/when you specify their size in pixels? I'm not sure exactly how that works -- I could be imagining a potential problem there that just doesn't exist, I don't know.

[Jellby]

Originally Posted by Psymon

Also, I don't really know alot about the "hardware" side of things, but with these newer hi-def tablets, how are "pixels" measured?

According to the CSS spec, px is an absolute unit, unrelated to the actual device pixel size. Most readers, actually ignore this and just use pixels.

You could use "cm" or "mm" too, and those are clearly absolute... but some devices (e.g. my Kobo) have a personal view on what a cm is.

And if using % for the margins/size, you should be aware that it may not change with font size, but it will change with screen orientation or device margins.

[Psymon]

Originally Posted by Jellby

According to the CSS spec, px is an absolute unit, unrelated to the actual device pixel size. Most readers, actually ignore this and just use pixels.

You could use "cm" or "mm" too, and those are clearly absolute... but some devices (e.g. my Kobo) have a personal view on what a cm is.

Hmm... well, this does certainly make for some interesting alternative ways of doing what I've been doing, but I'm still a bit hesitant, if only because I'd effectively be "disabling" the ability of the user to change the font size -- and don't you people keep emphasizing to me that I shouldn't screw with things like that?

And if using % for the margins/size, you should be aware that it may not change with font size, but it will change with screen orientation or device margins.

Yeah, I think I mentioned this earlier, but that's the very reason that I didn't want to go with %, and went with em instead, because I wanted my tables to be indented the same as I'd indented my poems and "blockquotes," and have everything all nicely uniform in that way (design-wise).

I think I'm pretty happy with how this all turned out, based on our earlier discussions here -- at least, testing in ADE and in iBooks, all seems to have turned out well (and I even managed to really simplify a lot of my coding for all the tables in my book in the process, which is a huge bonus, in light of the fact that I have a bunch more coming my way soon).

[RbnJrg]

Originally Posted by Psymon

Interesting thought -- although it brings to mind a couple of things. If you do that, then aren't you effectively defeating the whole point of allowing people to change the font sizes (re accessibility for people with poorer vision)?

In tables, yes, changing font-size will be disabled if we set font-size in pixels. Let's say that if we are going to follow this approach, we need to set the tables font-size in a point where reading is confortable (something equivalent to 1/1.2 em).

Also, I don't really know alot about the "hardware" side of things, but with these newer hi-def tablets, how are "pixels" measured? Like, something that's 72dpi will come out like that, but are hi-def screens higher than that, and then wouldn't the text (and various other things) come out much smaller if/when you specify their size in pixels? I'm not sure exactly how that works -- I could be imagining a potential problem there that just doesn't exist, I don't know.

Good point! By using pixels, texts that looks fine in some ereaders could appear tiny in others ones. Really I don't have an answer to this question of you.

[Psymon]

Originally Posted by RbnJrg

Really I don't have an answer to this question of you.

AWESOME! I said something that stumped even Rubén! I'm so proud of myself! I think I'll go out and buy myself a nice, big slice of chocolate cake now.

[DaleDe]

Originally Posted by RbnJrg

Good point! By using pixels, texts that looks fine in some ereaders could appear tiny in others ones. Really I don't have an answer to this question of you.

Actually Pixels is being touted as the solution to different screen densities. A pixel has been redefined to only represent one actual pixel on screens of so called standard density (usually defined as about 96ppi) on typical home computers and the higher density retina like displays are suppose to replicate or scale the size of their virtual pixel to approximate a similar sized image. This is the so called CSS pixel being advocated in HTML5.

Dale

[Psymon]

Thanks for the further info on pixels/screen res, guys! That does answer something that I've been wondering about for a while now, actually.

[Psymon]

Oh, one thing I asked about earlier, which I don't believe anyone responded about (having just skimmed over all the replies again), is with regard to tables not breaking when the page breaks in ADE. Like, I could have a bunch of text before the table that might go half-way down the page, but if it's followed by a larger (longer) table than would fit all together below that then that table gets bumped over to the next page -- and then you end up with a big white space at the bottom of the page, where the text is (before the table)... if that makes sense.

It occurred to me that one solution for this would be to do up every row of the table as a separate table -- but that seems like a ridiculous solution. Is there any more reasonable solution to this, perchance?

[Hitch]

Originally Posted by Psymon

Oh, one thing I asked about earlier, which I don't believe anyone responded about (having just skimmed over all the replies again), is with regard to tables not breaking when the page breaks in ADE. Like, I could have a bunch of text before the table that might go half-way down the page, but if it's followed by a larger (longer) table than would fit all together below that then that table gets bumped over to the next page -- and then you end up with a big white space at the bottom of the page, where the text is (before the table)... if that makes sense.

It occurred to me that one solution for this would be to do up every row of the table as a separate table -- but that seems like a ridiculous solution. Is there any more reasonable solution to this, perchance?

No. That's the solution.

Hitch

[Jellby]

Originally Posted by DaleDe

the higher density retina like displays are suppose to replicate or scale the size of their virtual pixel to approximate a similar sized image.

Yes, but it's the bold part that doesn't always work.

As I said, there's "cm", "mm", "in" and "pt", which don't have that kind of ambiguity (I mean, their name is clearly absolute), and can be used when an absolute length is wanted. But implementation-wise they probably have the same problems as "px".

[Psymon]

Originally Posted by Hitch

No. That's the solution.

Well, that sucks.

Geez, I spent all last night re-doing all the tables in my book -- I'm gonna have to think about this. There's a lot of shorter tables in it -- just two or three lines or so -- and I suppose I can keep those as one single table, but I guess it is a thought to split up the bigger tables into smaller ones. I suppose I don't have to do each and every row like that, but even if I did every two or three rows separately, then that might work out.

This could be interesting -- a total pain in the butt, but at the same time interesting, kinda like playing a "puzzle game" or something (with some of the tables, anyway).

[DaleDe]

Originally Posted by Jellby

Yes, but it's the bold part that doesn't always work.

As I said, there's "cm", "mm", "in" and "pt", which don't have that kind of ambiguity (I mean, their name is clearly absolute), and can be used when an absolute length is wanted. But implementation-wise they probably have the same problems as "px".

You are right that it doesn't always work due to the fact it is a rather new attempt at a solution and as I mentioned is is part of the HTML5 initiative so is not applicable to older devices. At some point you just have to consider old devices for what they are. Amazon has demonstrated that you can migrate from an old mobi format that is not even HTML4 compliant to a HTML5 by tolerating two displays that are not the same quality. The new px solution has the advantage that older devices continue to work even though the screen size isn't quite the same. And you are right, in practice the real values of cm, mm, in, and pt aren't not properly supported either and probable will never be.

Dale

[Jellby]

Originally Posted by DaleDe

You are right that it doesn't always work due to the fact it is a rather new attempt at a solution and as I mentioned is is part of the HTML5 initiative so is not applicable to older devices.

It is also included in CSS2.1 (http://www.w3.org/TR/CSS21/syndata.html#length-units):

px: pixel units — 1px is equal to 0.75pt.

At the time of the ePub 2 spec, CSS2.1 was still a working draft, so you are also right that it's not entirely applicable. However, this pixel definition has been in CSS2.1 since 2010.

Anyway, the message is that one can never know what a px will be, even in the absence of bugs.

[DaleDe]

Originally Posted by Jellby

It is also included in CSS2.1 (http://www.w3.org/TR/CSS21/syndata.html#length-units):

px: pixel units — 1px is equal to 0.75pt.

At the time of the ePub 2 spec, CSS2.1 was still a working draft, so you are also right that it's not entirely applicable. However, this pixel definition has been in CSS2.1 since 2010.

Anyway, the message is that one can never know what a px will be, even in the absence of bugs.

I am talking about http://www.smashingmagazine.com/2012...ds-retina-web/

edit: See also http://www.w3.org/TR/css3-values/#reference-pixel

Dale