I think I understand the steps you mentioned. So, ‘byte offset’ is the keyword for the freelancer to look for further stuffs, right?
However, I don’t understand the purpose of that ‘detect scrollbar’ thingy. As per my imagination, the reading dock will look really like an open book’s 2 pages, and thus has no scrollbars.
The density makes it look like… the abs of a horseshoe crab
On a remotely related topic, can you guys list your favorite serif, sans and mono fonts? Only 1 in each category please, that’d make 3. Maybe another honorable mention at most 
The software, reading from your source file, does it one character at a time. Each character in a standard plain-text file is one byte, and so it’s just counting the number of characters from the beginning of the file. When it has to do the next page, it knows where to resume reading.
The idea would be, from a given location, to read characters out of your raw file and place them in the display area, stopping when it’s full. Obviously you don’t want a scrollbar, but a lazy way to detect when to stop adding characters is to detect when an imaginary scrollbar would appear. A “smarter” way would be to programmatically control linebreaks and justification, but that’s likely to be more programming work.
If I understand correctly, you want to be able to take an arbitrary webpage (‘article’) and display it in your kindle-style, paginated reader, right? I think you - or your code - will really struggle with that given how flexible HTML/CSS is with layout, as well as potentially dynamic elements. You’d really need to strip out most of the complex layout first, similar to what browsers can (sometimes) do to go to a simplified reading mode, and then show that in your viewer. If you can get to where you’re just needing to display text, with some small amount of text designated as headers and whatnot, then what you’re talking about should be relatively easy for anyone somewhat skilled in the arts of web development.
Nitpick : Devices like the Kindle can display àccéntêd çhàractèrs without too much fuss, and probably Chinese and right-to-left scripts (such as Arabic) too, so I’m sure characters are encoded in Unicode inside (≥ 1 byte per glyph).
So our intuitive notions of “next page = the one on the right” and “first word = the one in the top left” are all happy memories of the distant past to the Kindle programmers.
I did a fair amount of bug fixes for RTL languages (Hebrew and Arabic) way back in the day. At the time, if you set Windows to one of those languages, the coordinate system flipped so (0,0) was the upper right. Where it went wrong was if you had images that you did not want to flip - you had to make sure those were specially marked. (IE, it was much more common on RTL systems to see something that should not have been flipped but was than vice versa.) I assume Kindle does something similar - I’d imagine that, most of the time, the developer does not need to be aware of whether or not it’s displaying L2R or R2L.
If you’re going to really get into the weeds of this, you will know how many bytes were required per individual character based on the charset being used. Pure plaintext for English is UTF-8, plaintext for other languages can be UTF-16 or uses some kind of markup plus unicode encoding for special characters. It’s going to be one or two bytes per character of source, always, and that won’t change the byte offsets of where the end of page is calculated to be.
The complexity is only if there’s markup that can change font size, kerning, or what-have-you, in which case (in fear of repeating myself) you have a more complicated programming task to decide when the page is full, but previously-calculated pages can still be reached with those byte offsets.
And if you want to get really fancy, you render the book once, calculate the byte offset of each page, note that down in a convenient array, and you can skip pages at will with ease. Whether it’s one or two bytes per character (being UTF-8 versus UTF-16 versus some kind of markup language) doesn’t really make a difference to the renderer.
It’s very unusual for non-English text to be encoded in UTF-16 or any fixed byte size character set these days. UTF-16 isn’t actually a fixed-width encoding anyway: characters with a value larger than 0xFFFF require using a surrogate pair (4 bytes) to encode. Almost all text nowadays is encoded in UTF-8, which is uses between 1 and 4 bytes for each Unicode character. ASCII is a subset of UTF-8, so saying “English is UTF-8” is kind of misleading – all Unicode characters can be encoded in UTF-8, but when Engish is encoded in UTF-8 it’s the same as plain old ASCII.
There are also a number of complications: some Unicode characters don’t actually display anything; they are “combining” characters which modify the previous character (deliberate overuse of which results in Zalgo text), and other characters are “double width” which display as twice as wide as normal characters. This all makes it fairly nontrivial to determine how much space on the screen a segment of bytes will use, even in a monospace font.
All the articles are written by me, so chances are they can be reduced to simple reading mode alright. However, I can imagine that my post will most often contain pictures and sometimes, (YouTube) videos. But that just need a somewhat simple resizing feature that match the pic/vid’s width to that of the page… right?
By ‘markup’, did you mean the text body has some characters that are formatted as BIGGER or smaller, so it’s hard to calculate total character width, right? Unfortunately, I do intent to use that method to emphasize in my posts.
Or, did you mean if there’s a button that allow users to change fonts, sizes or spacing, then the dock is ruined?
Hey thanks, now I know how those weird comments were made. OTOH, this complicates the picture. But then, how do those media where the Zalgo texts appear (YT, fb, etc) know when a comment has taken all of posited space for a line and break it down to the 2nd line?
I wonder about simple Office stuffs, such as MS Word. How does it know when a page is full and switch to the next page when we continue to type? Can we apply that to our problem too?
Oh, that certainly constrains the problem. Are you writing the articles for publishing only within your viewer, or are they also going to be published to a website where you want someone with an arbitrary browser to read them?
Regardless, the problem is that HTML is designed to give maximum flexibility to the webpage author. You can choose to always use it in a way which is sufficiently constrained so it works easily with your viewer, but you should probably just target ePub for the documents instead - it’s an open standard for publishing things like eBooks. Just poking around, it looks like it supports images and video fine. I’ll admit that I haven’t done much with ePub, but the fact that it’s a common standard would give me confidence that it can meet your use case.
All that said, I’m not clear what issue your developer is running into exactly. Yes, you have to dynamically go through each word, calculate its size based on the current font and size, and then do the layout ‘by hand’, but that’s not exactly rocket science.
I think your best bet will be to put your articles on Scribd, and then embed them in your blog pages.
The article will then appear inside Scribd’s document reader on your page. Scribd has Kindle-like display options. Simple and effective.
Software. 
It’s just (ha!) a matter of writing code that understands how to display arbitrary text and knows how to measure its size on the screen. It’s a complicated problem. I’ve been maintaining a piece of software for over 30 years which displays simple monospaced text, no proportional fonts, no embedded images, etc. and it’s still extremely complicated. After 30 years I’m still finding bugs in certain pathological cases. One of the smaller, but still annoying, issues is that Unicode is a moving target. I need to periodically download the Unicode database to know which new characters and (goddam) emojis have been added which may be double-width. I can say with a fair amount of certainty that you DO NOT want to write this code yourself from scratch. You need to find a library or some other mechanism to leverage existing code that knows how to display text in a defined rectangle.
I’m curious what the issues are that you’ve run into with the relatively constrained problem you’ve stated, beyond needing to keep your character width table up-to-date.
But that said, I agree that I wouldn’t recommend trying to write and maintain this by hand, especially because the OP (or his dev) doesn’t have to. It’s running in the context of a browser, so tell it to do it! Here’s one stackoverflow discussion of how to do it with HTML5, though there are other techniques, too.
Oh man, don’t get me started. Here are a few examples.
My app handles SGR escape sequences to change text attributes (bold, italic, color, etc), although similar issues would arise with any embedded formatting like HTML markup. Say you’re on page 15 and the user jumps to page 487. But on page 243 there’s a sequence that changes the text color. To know about that you need to process all the text between page 15 and 487 even though you’re not displaying any of it.
Suppose you have a double-width character which starts one space from the right margin. What do you do, display the left half of the character at the end of the line and the right half at the start of the next line? That would be ugly even if it were possible. The only reasonable thing to do is leave a space at the end of the line and display the character on the next line. Another special case for the code to handle.
My app has a line truncation mode, so instead of wrapping a long line to the next line it just truncates at the right margin. In that mode the user can scroll horizontally left & right. Scrolling sounds easy, right? If you’re scrolled 10 spaces right, you just discard the first 10 characters on each line. But wait, what if there is a formatting sequence in the first 10 characters? You can’t discard it; you need to extract it from the surrounding text and output it so the rest of the line is the right color. What if there are several formatting sequences?
Suppose the line is scrolled so half of a double-width character appears at the beginning of the line. It’s similar to #2 but the solution is less clear. If you leave a blank space there it may look like a character is missing.
In truncation mode, when you output a character at the right margin, you just stop outputting and skip over the rest of the line, right? No, what if the next character is a combining char that modifies the char at the end of the line? You need to check for one or more combining chars before you can decide you’re done with the line.
These are just a few recent ones off the top of my head. I could probably list a couple of dozen things like this. Granted, some of these wouldn’t apply to the OP (since they’re probably not doing anything resembling my truncation mode), but they will have other problems that I don’t have, like dealing with proportional fonts (a big one), kerning, embedded images, and so on.