lee said:

I would argue that one of the most important lessons of the internet is that there is practically no such thing as an "average" user.

while i know what you're trying to say, i also know well that only a very small percentage of people use portrait monitors. and about half of the small few who do have _2_ monitors, so they are essentially creating one big landscape screen...

If you ever come across a web site where you have a right/left scroll bar (and there are many) you know you have encountered a web designer who's stuck in the desktop publishing world.

most designers today know a horizontal scrollbar is bad... so what do they do? they keep the same old bad design, and they just rip out the scroll bar. so if your viewport is too small to see the whole thing, you're just out of luck... some well-regarded designers think this is acceptable! the whole "reflow" propaganda is, in large part, a big lie.

two monitors, side-by-side, both rotated into portrait mode ... I can stretch a window across the two monitors

i see, so you _were_ just being perverse... and thus my advice to you would be to stretch that window across the two monitors, such that one half of the display is on the left monitor and the other half of the display is on the right, all nice and convenient. but thanks for keeping me on my toes.

Yes, I have similar problems at the FadedPage site, although it's not quite as bad as they have only a single frame containing the page image.

well, just to be clear, rfrank isn't using "frames" at all... but yes, i could have the user specify some numbers and then i could cram the page-scan into a box of that size, which is what rfrank is doing. (and i believe d.p. as well.) but i'm not sure that's the right thing or the best thing...

I am finding that the problem is really coming down to the issue of being able to scale the image, not any of the surrounding controls.

bingo. and that's what's frustrating about doing this in a browser, because you want some kind of if/then branching capability so you can _change_ what you do relative to the _situation_. in order to get that kind of functionality, you've gotta go to javascript, and now we're stuck in a whole other ball of wax. and when a user wants to change the scaling -- on the fly -- you've got still more headaches, cured only by a dose of ajax. i'm not saying it's impossible, but it's certainly not _easy_... with my offline apps, though, it's a piece of cake. with frosting.

With a width of 1050 (the maximum resolution of my particular monitors) to reduce the text to a point where I get anything like the kind of layout you describe the text becomes so small as to be illegible; the reason is while I can reduce the font size I can't reduce the page image size, which is really about twice as large as it needs to be to be legible.

ok, first, my demo uses rfrank's scans from the "sitka" book, and he has adopted the rather irritating practice from d.p. of blowing up the size of the scans. so the scan itself is "too big". for instance, the scan of page 23 measures 1211*1912 pixels. and you can be assured that the book was not _really_ that big. so that's the first fly in the ointment. the second is that i set the image scaling according to its height. if you view the source on my page, you'll find this: height="90%". that scales the image to take up 90% of the height of the viewport, meaning one gets to see the entire page in one's browser-window. that's the good news, anyway. the bad news is that, as you found, on portrait screens, the window's height is so big that the image becomes so large it uses more than half the width of the screen, and thus compromises the basic design, to the point of disaster... the other bad news, as jim found, is that on a widescreen monitor, the image takes up much _less_ than half of the screen. while this is not a "disaster", it's certainly not the preferred thing. i hasten to add that -- on a "regular" 1024*768 landscape monitor that _most_ people use these days -- my image scaling works _nicely_ for them. (although i recommend using full-screen mode for the best effect.) but yes, what needs to be offered is a way for an end-user to plug in the particular scaling which is to be used for that particular situation. or we need a javascript program to determine an acceptable solution. (and maybe an option for user-override to accommodate preferences.) and then, as i have said before, the ability for the user to manipulate the interface at will -- with divider-bars or what have you -- is good. but honestly, given the glacial pace at which web standards evolve, it might be 5 or 10 _years_ before it is _simple_ to do in a web-app the kind of things i can do with my offline apps _right_now,_today_. so for me, this web development is just a nice little distraction that makes it easy for me to show off the general ideas i have in mind. if i ever really have people proofing, they'll do it with offline apps.

If you want any screen shots of the various configurations I've tried, I'd be happy to e-mail them to you.

if you post them, so other people can see 'em too, that'll be best.

These radio buttons don't seem to work at all with Firefox 3.5.8 on Windows XP.

that's weird, as i tested it on windows in firefox (version unknown). the radio-buttons don't change anything when you _click_ 'em; you must summon another page for the change to take effect. try that. (but yes, for that reason, i'll probably change the radio-buttons into a standard button that will toggle between the two states.)

Fair enough. In this case I think you need to include some sort of access to the easy explanation from the page itself.

nah, that would just be more page-clutter to the trained users. the training will take place when new users encounter the site... (and during their early days, as they encounter diff experiences.)

s.m.l. => Spousal Markup Language. So called, because while there are rules, one has to figure them out for oneself ("it's so obvious I shouldn't have to tell you what they are") and because they're so subtle that one can't really tell when they've been broken. :-)

cute... but entirely inappropriate. as you well know... you always remind me _why_ you're in my spam folder. so, as you know, lee, and as many other people here know, the "rules" of z.m.l. have been posted for many years now...

http://z-m-l.com/go/vl11.zml

that file's been up for over 3 years now -- february 2007 -- and other versions were floating around long before that one. indeed, they have been posted for so long that they probably include some small sections that are out-of-date by this time. but for the vast majority of them, i'd say they are well-known. if you really _want_ to know them, that is. on the other hand, you can ignore them if you want, likely with very few ill effects. just don't come around here _broadcasting_ your ignorance... and although the rules might be called "subtle" by some people -- most notably people who can't differentiate it from "zen" -- the fact is that people operating inside my proofing system can indeed "really tell" if/when they're using z.m.l. correctly, because the .html field looks like the p-book page as shown by the scan. and if it looks wrong, it means you've done the z.m.l. incorrectly. so there's an immediate w.y.s.i.w.y.g. feedback mechanism there.

Proprietary simply means "property of."

don't come around here and use solely denotative definitions... because we all know you're using that word for its spin value, which is contained in the connotative. but you don't have the huevos to be specific about the negative connotations, so you try to avoid a conscious consideration of their applicability by using a blanket term. spin is used by cowards to sidestep dialog.

You have invented the markup language, and I suspect you would take umbrage if someone else were to try and alter it.

why would you want to "alter" _my_ invention, instead of just creating your _own_ invention that's almost-exact-yet-altered?

Anyone can use it, but you "own" it.

right, because i'm not gonna let someone like _you_ come in and "alter" it to the point of _ruining_ it, so no one will use it.

It is thus proprietary.

i'm not gonna let you ruin it, no. you can use it, for free. you can modify it, at will, to your liking, just as long as you don't refer to your modified version as "z.m.l." you can build tools, either for my version or for your new mutant. you can use the tools that i've built, for my version, at zero cost... there's no need to reverse-engineer the format, because i have provided explicit documentation on it, and am _right_here_ to answer any questions you might have about it, so that's ducky... but i'm not gonna let you ruin it, no.

This situation is neither good nor bad, it's simply the way it is.

it must be sad to be a man who has no huevos... -bowerbird