Dimension confusion

I have been assuming that "length" refers to what I would call "width", and most of the books I enter seem to have corresponding measurements (that is, the width is shorter than the height for most books).

However, I have noticed some where the numbers are flipped, and in one memorable case, "thickness" was confused with "height", resulting in a very oddly-shaped book.

Is there some reason why it says "length" instead of "width"? I've never referred to a book's "length" in English except in terms of how many pages it has. (How long is this book? It has 353 pages.)

Assuming there is some reason for this terminology (and it can't just be changed), could there at least be a ? or i that you can click or hover your mouse over and see a little diagram?

I agree that this is confusing. I think thickness, width and height would make the most sense.

>1 AranelST: Different libraries enter this differently. Some seem to call the longest measurement the height. Perhaps they tend to store oblong books on their side. What ever the reason they do this, it makes little sense. The height of a book is what you would get if you placed a ruler running up and down on the front cover of the book (holding it as if you were reading the book).

Indeed, height should depend on the orientation of the text, and in cases where that is ambiguous, the orientation of the spine.

Personally, I would associate the 'width' of a book with what is described as its 'thickness'.

In my mind, 'height' is from the top of the cover (or spine, since the measurement would be the same) to the bottom, 'length' is from the spine side of the cover to the open side of the cover, and 'width' (or 'thickness') is the measure of the spine from one joint to the other, ie how wide the spot on my shelf needs to be to tuck it in between two other books.

If I understand the situation correctly, the suggested informational pop-up in >1 AranelST: won't really accomplish much.

Different sources are inconsistent about how they attribute the three dimensions to book measurement, so there's no assurance that any particular imported record will use the "standard" orientation.

Physical dimensions are book-level data, so they aren't shared between different copies in LibraryThing anyway. They can't even (short of heroic measures coded outside the platform) be copied from another user's book.

It think it depends on whether you are (imagining that you are) looking with the cover or the spine facing you.

In physical libraries, books "live" on shelves, so it makes sense to me that some people might think in terms of the spine, which is usually what faces outward.

But Library Thing always seems to prioritize the cover view, which you might see when you are holding a book in your hands. It's a 2-dimensional image, with height (x) and width (y), and the thickness (z) is implied to be behind it. I just now was extracting a cover image from a PDF using GIMP, and the dimensions are height and width.

It seems to me that even if these are traditional library terms, the medium is digital, and average users are more likely to think in terms of digital images. However, if it's going to be confusing either way, perhaps "length/width" would be a better label? Or "length (width)"?

>6 paradoxosalpha: Physical dimensions are book-level data, so they aren't shared between different copies in LibraryThing anyway. They can't even (short of heroic measures coded outside the platform) be copied from another user's book.

I am constantly getting dimensions in green text, which is supposed to mean it was "calculated" somehow. Other times the dimensions are in black text. Where is this coming from? I'm not entering all of these numbers myself.

In any case, knowing what the dimensions are supposed to mean would help users who are entering their own data. (There does seem to be an intended meaning, as it appears in the charts and graphs.)

There is an interesting historical explanation of sizes at . https://en.wikipedia.org/wiki/Book_size, which is well worth a quick read.

My vote would be (as looking at a cover page not the spine)
Width of page x Height of page x Thickness of book.

>9 JonathonL88: Referring to the pages is a great idea!

There's a lot of very bad data in the system most of it seemingly originating from Amazon. According to the stats the average book in my library is a foot high, 4 1/2 inches wide and nearly 3 inches thick. As I don't own a medieval chained library this does not resemble reality. I suspect this comes from people on low wages employed to do data entry and the fact that Amazon probably only care about shipping dimensions so getting height and width mixed is of no consequence.

We can be certain the smallest dimension is the thickness (the spine would collapse as soon as you opened if it exceeded any of the other dimensions).

Most books are taller than they are wide (it's a stronger binding) but not all, typically art and photography books that display work in landscape.

However a large percentage of books ( I think as much as a 1in 5 or more from a sample I took once) have dimensions incorrectly labelled so I think it better if they were just recorded as N x N x N and not labelled at all.

The definition of the dimension stats on Librarything are simple:

Height: Spine from top to bottom
Length: from spine to opposite edge of cover
Width: Could also be thickness, so how wide is the spine

>9 JonathonL88: On most hardcovers the cover is larger than the pages.

Three-dimensional objects are, in my experience, usually said to have height, width, and depth. So:

"Height: Spine from top to bottom" - I too would call this height.
"Length: from spine to opposite edge of cover" - I would call this width.
"Width: Could also be thickness, so how wide is the spine" - I would call this depth.

Could there be a little diagram next to the input fields, labelled with which dimension has which name?

>14 DuncanHill:
"Height: Spine from top to bottom" - I too would call this height.
"Length: from spine to opposite edge of cover" - I would call this width.
"Width: Could also be thickness, so how wide is the spine" - I would call this depth.

Hmm; I, personally, (at least at this point in time - could change without notice 🤗) would consider it looking at a book on a shelf so:

Height: Spine from top to bottom - I would call it 'height', too (fairly unambiguous)
Length: from spine to opposite edge of cover - this I would consider 'depth', corresponding to shelf depth
Width: Could also be thickness, so how wide is the spine - yes, 'width' or 'thickness'

... yup, a diagram would be useful :0)

Repeating my earlier post...
My vote would be (as looking at a cover page not the spine)
Width of page x Height of page x Thickness of book.

>16 JonathonL88: Except the charts and graphs include amount of shelf space required, so would need to include the covers as well.
Your idea doesn't work.

Fair point. How about...

Width of page x Height of page x (Thickness of book including covers).

>18 JonathonL88: Covers are often higher and wider than the pages.

>14 DuncanHill: >15 humouress:

Here you go, LibraryThing can use this free of charge.

As a representation of a library, it makes sense for LT to define book dimensions as a book would appear on a shelf, spine out. Thus width would be the width of the spine and depth would be how deep the book protrudes into the shelf.

>21 jjwilson61: There's the rub: everyone agrees on the 'z' axis, but 'x' & 'y' are ambiguous depending on how you take in the book: as a cover or as a spine.

I never trust the auto-generated dimensions anyway, because they often will be incorrect for my specific books, or rounded up or whatever.

I do not find "height, length, thickness" to be confusing. I think length could be ambiguous on its own, but in the context of height and thickness, what the third dimension refers to becomes obvious.

Referring to the thickness of a book as the "depth" would increase ambiguity, and I disagree with that. You need terminology that is clear regardless of how the user perceives the default orientation of a book. The average user is more likely to think of a book with many pages as being 'thick' rather than 'deep'.

My suggestion: just put all the possible names for every single dimension in front of the fields together and see how helpful that is. :)

Even thickness is ambiguous as books rarely measure the same shelf-out (spine) and shelf-in (paper side). Paperbacks spay with reading, so thicker measured shelf in, and hardbacks are sometimes the opposite, sometimes not.

(Not accounting for the fact that hardback spines are often curved (and tricky to measure) or the effects of different bindings, spiral bound, saddle-stiched etc. (Arguably the spine width of the latter is nominally zero). I've taken to tracking my reading in linear/shelf cm and measuring the shelf-in side gives more consistency).

I think we actually need two sets of dimensions:
reported (what we have now, arguments about labelling aside) and normalised i.e. the 3 dimensions, without labels, in order of size.

The latter could be used for calculations. If you want to know how much shelving you take the sum of the smallest dimensions. Figuring out suitable shelf-height* is trickier but you can take a percentile of the largest.

I live in a 'two up, two down' terrace that's fairly small by UK standards for similar houses (and close to Tiny House by US standards) so I had to do a lot of careful measuring and some maths to figure out how to get all the books in. Librarything was sadly no help since dimensions are so frequently mixed up.

* 28cm seems to be the library standard for 'oversize' but I calculated that 25cm was a good standard shelf height (I think ~90th percentile with room to take them out easily from the top when a shelf is full). 34cm does it for most oversize books (and I left the cases open topped so the top shelf is ~50cm below the ceiling which takes care of the rest and the inevitable tottering piles now the shelves are pretty much full).

>24 tallpaul: Normalising in order of size would fall down with landscape books if you want them spine out...

>24 tallpaul: Ah, you really only need the volume. (If HouseVolume < CombinedBookVolume: Buy new house Else: No worry). And I'm in the same boat. Thanks for the picture!

Well it does look like we need more than one word descriptions, for clarity. Do these work?:

spine width (corresponding to d in >20 DuncanHill:)
spine height (corresponding to h in >20 DuncanHill:)
cover width (corresponding to w in >20 DuncanHill:)

>25 Maddz: In theory, yes. In practice the data is is very messed up, and dimensions are frequently mislabelled, so normalizing would be more accurate, when talking about averaged data. Looking at the cover image would be better for an individual book.

>28 tallpaul: I _think_ that's how Amazon sees it. What would the package look like? So they don't care if a book is landscape or portrait.

>29 bnielsen: Whereas in terms of managing a paper book library the correct dimensions do matter:

-How many books are too tall to fit in a bookcase with fixed shelves?
-If the books are shelved spine out, what's the total length of shelving needed?
-What's the depth of shelving required?

And so on...

>30 Maddz: I think I've seen examples where Depth: (i.e. no depth given) was converted to Depth: " ", (i.e. a space) and then to Depth: %20 (i.e. on a web page somewhere) and then to 20 cm or 20 inches. So it is always a good thing to look for outliers in data!