Weird page count issue.

[IWroteThis]

So much for the idea that the Lit page length was tied to a maximum character count - a max field size. Obviously not!

Not necessarily. The database records that hold the submitted content is not the same as whatever caches the results of pulling and processing the data in those records.

It's quite possible that either the mess of white space or it falling at the field limit broke the automated process that converts the story text into display-ready HTML files. (Based on the way stories and story edits are deployed, it's safe to say that every story text section for each page of each story is generated at once, even if the various cached components are combined into a new page when you click on the link for each page.)

If that break resulted in a page or pages being skipped, it would probably be easier to manually add the missing story text to an existing page rather than adding a new page.

It's less likely, but the mess of white space could have just masked the end of record marker, causing the automated process to include the text from a second record before the next marker actually triggered pagination.

Sorry, but it's actually not so obvious.

 

[ElectricBlue]

Sorry, but it's actually not so obvious.

It's certainly unusual. I've been here for eleven years, this is the first occurrence anyone has reported of a super long "page".

 

[Britva415]

I agree, but preview wouldn't help with pagination, would it?

It would help you see that your paragraphs break where they're supposed to. Which is the point, if what's being recommended is that you simply enter linebreaks in your text instead of spamming <br /> tags where you think they belong.

 

[IWroteThis]

It's certainly unusual. I've been here for eleven years, this is the first occurrence anyone has reported of a super long "page".

Oh, I certainly agree that it's unusual!

 

[IWroteThis]

I looked at the HTML and it's uncanny. Here's a sample:

View attachment 2597971

Those <br>'s should've been <p>'s, i.e., paragraph breaks, instead of just line breaks. Basically, each separated section / scene in the story is physically one gigantic paragraph, so there are maybe 5 or 10 of them per each (large) page.

It's reasonable to assume the pagination procedure has some minimum number of paragraphs per page; and if the "paragraphs" are so big, then it might think it has stuffed only like 5 of them on the page, reaching said minimum, despite the fact it results in 7k+ word pages.

@ghastly_lump_of_meat How did you submit the story? Word doc? Or the submission form, with those <br>'s inserted manually?

And, we have a winner!

Looking at the HTML code for the first page, it looks like there were only 5 hard returns in the corresponding original text. You can tell, because hard returns are the marker for a new paragraph, and each paragraph is encapsulated in its own p tag.

The first hard return comes after 1,845 characters of HTML code. The second after 957, then the third after just 17. The fourth comes after 11,093 more. That is still short of the new page trigger, so it adds the 34,061 characters between the fourth and fifth hard return before paginating.

I didn't do the character counts on the second page, but there are only two hard returns indicated. The first comes just after the two BRs and three em dashes at the very top, so less than 100 characters. Everything else on the second page is between the the first and second (last) hard return.

Ironically, the third page is considerably shorter than either of the first two, yet has four hard returns in it.

So, despite the white space displayed from BRs, that 26K story is only eleven paragraphs long.

 

[IWroteThis]

It's certainly unusual. I've been here for eleven years, this is the first occurrence anyone has reported of a super long "page".

(grumble)(grumble)(grumble)

I still believe the pagination length was at least originally tied to the field size in the database, but I'll admit that, after further examination, this incident might support the current field size not being that small anymore.

(grumble)(grumble)(grumble)

I hate admitting I'm wrong, but mostly because I hate being wrong!

(grumble)(grumble)(grumble)

In my defense though, it clearly wasn't obvious, as I was able to come up with two other explanations. Also, your use of past tense implied it was never true, which no current data could prove, as I know they've modified both the database and the code base many times since then.

So, I'm going to call it a draw. We both were partially right, and we both were partially wrong.

 

[NotWise]

Don't know about your stories, but the pages on my stories break between paragraphs after 20,000 characters. The break may fall after the paragraph that reaches 20,000 characters or before it, but it always falls between paragraphs. It's probably systematic, but details of exactly how characters are counted obscure the system.

IF pages only break between paragraphs, and the story contains huge paragraphs, then the pages are going to be long.

 

[ElectricBlue]

(grumble)(grumble)(grumble)

I still believe the pagination length was at least originally tied to the field size in the database, but I'll admit that, after further examination, this incident might support the current field size not being that small anymore.

(grumble)(grumble)(grumble)

I hate admitting I'm wrong, but mostly because I hate being wrong!

(grumble)(grumble)(grumble)

In my defense though, it clearly wasn't obvious, as I was able to come up with two other explanations. Also, your use of past tense implied it was never true, which no current data could prove, as I know they've modified both the database and the code base many times since then.

So, I'm going to call it a draw. We both were partially right, and we both were partially wrong.

I'm not debating anything. All I'm saying is the supposition there's a fixed bin size of xx thousand characters can't be right, coz we've seen a 9k word long page. Empirical proof conquers any supposition!

 

[TheWritingGroup]

It sounds unlikely to me that the page size limit was based on database record limits.

It's based on wanting to balance ease of reading (to retain readers) with maximum number of ad impressions (to increase income).

 

[ElectricBlue]

It sounds unlikely to me that the page size limit was based on database record limits.

It's based on wanting to balance ease of reading (to retain readers) with maximum number of ad impressions (to increase income).

25 years ago, it might have been a technical limit. It's not uncommon for legacy systems having design elements left over from prior versions, that no-one bothered changing.

The first ever spreadsheet I used, for example, had 26 columns and only 256 rows, and prior to DOS (a very low number), file names had a limit of eight characters. The Y2K scare was caused by developers saving space on the field size for "year", using only two characters, not four.

Blogger, as a more recent example, has a Comment field length of 4000 characters, which isn't huge.

 

[IWroteThis]

It sounds unlikely to me that the page size limit was based on database record limits.

It's based on wanting to balance ease of reading (to retain readers) with maximum number of ad impressions (to increase income).

It sounds unlikely to me that you've done database work.

Also, that doesn't make sense, as the current page length is longer than optimal for reading, and more pages increases the number of ads presented.

Instead, it sounds to me that it was picked to minimize database size. Back then, every MySQL database record was padded out to the maximum length of all the fields. Thus, a story that required two records took twice as much space on disk as one that fit in a single record, even if the second record only had a few words in the story text field. So, to reduce costs, you would want to fill that field as full as reasonably possible before moving to a new record. Setting the page length based on HTML code that would fill the field to within a reasonable safety margin was the most cost effective on the back end.

 

[IWroteThis]

I'm not debating anything.

Show, don't tell.

25 years ago, it might have been a technical limit. It's not uncommon for legacy systems having design elements left over from prior versions, that no-one bothered changing.

The first ever spreadsheet I used, for example, had 26 columns and only 256 rows, and prior to DOS (a very low number), file names had a limit of eight characters. The Y2K scare was caused by developers saving space on the field size for "year", using only two characters, not four.

Blogger, as a more recent example, has a Comment field length of 4000 characters, which isn't huge.

That's exactly the point I was trying to make. The length of normal pages has not changed, so the current pagination of stories is still determined by the original criteria. Pointing to a rare case that appears to have happened to work more so than actually being expected by the code does not disprove that.

 

[RejectReality]

Show, don't tell.


That's exactly the point I was trying to make. The length of normal pages has not changed, so the current pagination of stories is still determined by the original criteria. Pointing to a rare case that appears to have happened to work more so than actually being expected by the code does not disprove that.

Probably something they should fix, because it's exploitable. This is an extreme example, but if you tweaked every page to be a bit longer, you could knock a page number or three off your total, and that could make a difference on who would consider continuing. It would be pretty easy to knock off that 4th page that's something of a cutoff for the stroke readership, and the additions to the remaining three wouldn't be super stupid obvious.

 

[TheLobster]

Honestly, this can sometimes be a feature. Like, if your story is between 10 and 11k, and you’re worried you’ll get the dreaded fourth page with a single paragraph on it, just merge the final few paragraphs with <br>’s. They’ll either stay on page 3 or all go to page 4, but you won’t get the orphaned paragraph.