This particular case is fixed. It came as a result of a bug in BackTalk which fails to account for the fact that someone may comment on an example. The bug still isn't fixed though, I just moved the comment. ----- Original Message ----- From: "Oliver Bleutgen" <myzope@gmx.net> To: <zope@zope.org> Sent: Tuesday, November 20, 2001 11:00 AM Subject: Re: [Zope] Line Wrap and the Zope Community?

Hi Ron,

Ron wrote:

...

Does Zope hard code carriage returns?

I'm new to Zope. I'm following a zillion links to Zope community pages, doc's, HOWTO's, etc. and finding on many pages I either have to scroll horizontally or increase the horizontal size of my browser (Galeon, though I've loaded a few pages in Netscape 4.7 with the same results) to view all the text.

Is this a limitation of Zope, an error imposed by the page designers, a design flaw in my browser OR WHAT?

The second I would guess, it's definatly not a problem with zope. It might help if you give some examples, here's mine:

http://www.zope.org/Documentation/ZDG/ComponentsAndInterfaces.stx

and many more pages in ZDG don't render well in either mozilla or IE, I get a huge horizontal scrollbar... So, this is more an issue of the zope-web(?) mailing list.

cheers, oliver

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

Note that lots of pages on Zope.org make the presumption that you're browsing at a screen resolution of 1024 x 768 or higher. It's unfortunately very difficult to accomodate lower resolutions and still be able to give example code mixed with narrative in any reasonable way. Note that the "standard" for Zope Python code is 79 characters wide *wihtout* \'s. When combined with a buffer on the left hand side, I can imagine the result running over 800 pixels. 120 characters is absurd, though, you're right. This is a problem with Python code in general. Lots of times I end up breaking semantics across lines for this reason. ----- Original Message ----- From: "Paul Winkler" <slinkp23@yahoo.com> To: <zope@zope.org> Sent: Tuesday, November 20, 2001 12:51 PM Subject: Re: [Zope] Line Wrap and the Zope Community?

On Tue, Nov 20, 2001 at 11:41:35AM -0500, Chris McDonough wrote:

...

This particular case is fixed.

I don't know what it looked like before, but the text still goes off the screen a bit on Netscape 4.74, linux, 800x600 display.

The cause? Long lines in the code examples, which of course are in <pre> tags and can't be wrapped. This causes the whole table to be as wide as the largest line in a <pre> tag. In this case, the examples aren't that long but for some reason there are 6 unnecessary blank spaces in front of each line. Maybe a stx issue?

I see this problem all over pages on Zope.org. Very often it's due to people posting sloppy code examples with very long lines. I've seen some code examples with a single line that's 120 characters long. People, please don't do that! Not only does it make your web pages scroll off to the right, it makes your code harder to read and understand, which is not nice to the newbies.

For example, browsing through the links from the first page of http://www.zope.org/Documentation/nuser: at least half of them have this problem. Some are very hard to read. Here's a particularly long line:

if search_expr=='' or string.find(string.lower(o.raw),string.lower(search_expr)) != -1 or string.find(string.lower(des),string.lower(search_expr)) != -1 or string.find(string.lower(title),string.lower(search_expr)) != -1 :

Simply break up the lines and it's much nicer, like this:

if search_expr=='' or \ string.find(string.lower(o.raw), string.lower(search_expr)) != -1 or \ string.find(string.lower(des), string.lower(search_expr)) != -1 or \ string.find(string.lower(title), string.lower(search_expr)) != -1 : ...

Also, there's a lot of redundancy... do we need to say string.lower(search_expr) three times? No. Assign it to a new variable. In this case, search_expr was never used again so we can simply reuse the name search_expr, like so:

search_expr = string.lower(search_expr) if search_expr=='' or \ string.find(string.lower(o.raw), search_expr) != -1 or \ string.find(string.lower(des), search_expr) != -1 or \ string.find(string.lower(title), search_expr) != -1 : ...

Another variation... at this point it's definitely a matter of taste (and maybe optimization):

from string import find, lower search_expr = lower(search_expr) if search_expr=='' or \ find(lower(o.raw), search_expr) != -1 or \ find(lower(des), search_expr) != -1 or \ find(lower(title), search_expr) != -1 : ...

--

paul winkler home: http://www.slinkp.com music: http://www.reacharms.com calendars: http://www.calendargalaxy.com

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

I'm a bit relieved someone has noticed... WAIT! Is this ENDEMIC to the Zope community? Is NOT the primary use of the web, i.e,. the WEB PAGE to present information for HUMAN consumption? And would NOT the best of this be a web page that presents itself so that the viewer DESIRES to view it? (Let me call this VISUAL ALACRITY*) Should it follow: It is the ULTIMATE goal of web publishing software to provide and enhance Visual Alacrity! (Especially in this era when it is NOT information, but the ability to CAPTURE ATTENTION that is at a premium!?!) Is Zope a data PUMP or a web PUBLISHER? A word wrap (or any display) problem is ONLY the fault of the SOFTWARE UNLESS the page designer takes EXTRA-ORDINARY steps to BREAK (what should be) THE SOFTWARE'S PRIMARY FUNCTION - Visual Alacrity! I swear, kids designing pages in HTML editors are producing more appealing results! -------------------------- Please, this is not an attack. I'm a (albeit new) member of the Zope community. 20 years of programming experience clues me that ZOPE is the BEST OF BREED! But the human part of me, the one that steps back and evaluates the work I've done in context to humanity (right, in CONTEXT to WHAT REALLY EXISTS, NOT JUST WHAT MY BUDDIES ARE DOING)... that part of me wants to vomit as I wade through on-line Zope sources in the process of educating myself. And it's NOT the contributors or their content that are at fault: IT IS THE MIND SET of the Community that allows this LACK of Visual Alacrity to become ENDEMIC to the entire Zope experience! WAKE UP! -Ron * Visual Alacrity: A cheerful readiness, willingness, or promptitude to be viewed; joyous reading, visual briskness, sprightliness. PS: Simon, I'm not dumping this rant on you, as you know, I'm trying to ratchet up awareness before I too am lulled into acceptance by exposure! It's not my intention to attack specific web pages since I do not view them as the problem nor listing them as a part of the solution set. The solution lies in making Zope a better Web Product, that means making its developers AWARE of what that ENTAILS and reminding users WHAT TO EXPECT!

You are right. This situation is truly appalling. It's right up there with the web's ubiquitous unreadable size-locked fonts (but perhaps easier to solve).

I'm not sure why it's so common, and the problem is certainly bigger than the zope community, but I'd like to see us take steps to prevent it happening on our turf. What can we do ?

Mike Renfro wrote:

Now, some of the issues with structured text are being addressed (http://structuredtext.sourceforge.net/), but for our immediate crisis, who wants to come up with a solution that will:

a) keep my code intact -- no extra line breaks, spaces, etc. unless I say so. No removals, either. If I print out a snippet of Python code that's been mis-indented because someone wanted a narrower page, I'll be irked.

b) not do horizontal scrolling on most/all monitors

c) keep a readable font size on most/all monitors

etc. Let's hear some viable solutions now.

Well, the solution would be to use IE's marquee tag or javascript + dhtml to move the line *really* fast horizontally across the monitor. Then hope that lorentz contraction will help you. Well, you'll need approx. 1/2*c to get a noticable effect, and it might no improve readility and will be resource intensive. ;-) Seriously, this is impossible, you can just achieve two of the three points you mentioned. cheers, oliver

On Wed, Nov 21, 2001 at 12:55:29PM -0600, Mike Renfro wrote:

Now, some of the issues with structured text are being addressed (http://structuredtext.sourceforge.net/), but for our immediate crisis, who wants to come up with a solution that will:

a) keep my code intact -- no extra line breaks, spaces, etc. unless I say so. No removals, either. If I print out a snippet of Python code that's been mis-indented because someone wanted a narrower page, I'll be irked.

It's a very tough problem. All these pages use table layouts; and even if you specify table width as 100%, that doesn't *really* mean 100% of the browser window - it means "100% of the browser window if everything fits, otherwise, expand outside the window as necessary." There's no way to prevent that from happening if an element of the table is too big. And browsers aren't smart enough to allow one really wide cell and still fit the rest of the table in the browser window. There are 3 ways to get a row too wide for the browser window: 1) include a really wide image 2) include a "pre" tag with a really long line 3) include a really long string with no whitespace 4) specify table width as a really large number of pixels. #4 is unlikely. On zope.org I think most of the problems are due to #2, with possibly some screenshots accounting for #1. #3 might come up if there's a link to a gargantuan URL. We *can't* prevent all of these from happening. For one thing, we never know what "really wide" means; somebody might be browsing on a portable device with a 200x300 display. You can find out with javascript ... *if* the client has javascript ... and *if* they haven't turned it off ... and *if* it works... Without knowing the display size, the best we can do is pick a reasonable width and try to force most things to fit that width. Two possible hacks that might help: 1) Modify stx such that normal (non-code) paragraphs are wrapped in a table cell with an explicit width of reasonable size. Pick this reasonable size empirically based on common browsers and displays. It'll look better sometimes, and worse sometimes. 2) Modify stx such that normal (non-code) paragraphs do explicit line wrapping using <br> tags. Again, pick a reasonable size empirically based on common browsers and displays. This has the disadvantage that it doesn't work if the user's preferences include some funky font size. Here's an example function: import string def explicit_wrap(paragraph, maxlength): input_words = string.split(paragraph) lines = [] while input_words: line = input_words[:] while len(string.join(line, ' ')) > maxlength: line.pop() input_words = input_words[len(line):] lines.append(string.join(line, ' ')) # handle the last line if len(string.join(input_words, ' ')) <= maxlength: lines.append(string.join(input_words, ' ')) break result = string.join(lines, '<br>\n') return result -- paul winkler home: http://www.slinkp.com music: http://www.reacharms.com calendars: http://www.calendargalaxy.com

Ron <theotiwii@earthlink.net> writes:

I swear, kids designing pages in HTML editors are producing more appealing results!

Whoops! Your rant broke loose :) Don't forget it's easy to produce one pretty page, a lot harder to ensure optimal display of all pages under all conditions. Just a few more datapoints on http://www.zope.org/Documentation/ZDG/ComponentsAndInterfaces.stx - I confirm that in a "standard"-width browser window - that is, about 2/3 of my XGA screen - NS 4.7 requires scrolling and mozilla 0.9.5 does. Konqueror 2.2 doesn't, cleverly enough. "Chris McDonough" <chrism@zope.com> writes:

Note that lots of pages on Zope.org make the presumption that you're browsing at a screen resolution of 1024 x 768 or higher. It's

I think that's almost never a reasonable presumption, alas. In the case of lines wider than the window, which can't be wrapped for whatever reason, I think it's perfectly reasonable for them to go off-screen and require horizontal scrolling. However, what frequently happens is that the entire page happily fills the new width and so now *every* line requires scrolling. This is what's particularly annoying, when you have to scroll to see things that you know your browser is perfectly capable of wrapping. I think this is mostly when the text is within a table layout. Most zope.org pages use a table layout and are vulnerable for this reason. I'm guessing slightly here. An easy solution is to not put the main page text in a table. This would mean giving up the left sidebar, typically putting menus & links along the top instead. This would also help the width shortage as well as improve page rendering speed; I think many sites have made this move for the same reasons. And as readers of this list over the last few years know, I wouldn't miss the zope.org Blue Zone too much. -Simon

Simon Michael wrote:

Whoops! Your rant broke loose :)

Ouch, you're right, sorry :-/ The problem isn't just Line Wrap, it's the whole "take it or leave it" attitude to presentation I'm feeling. Perhaps EXPERIENCED users on this list are puzzled by my admonitions since they aren't scrounging the Zope sites for HOWTO's, tutorials and the like, being EXPOSED to just how trying the process is. Okay, here is an example. The author of this page has my gratitude and praise for his/her contribution, but in my opinion Zope has failed BOTH that author AND me... Here's the page: http://cmf.zope.org/CMF/Members/beehive/ZWACKChap5.html 1. I run at 1600x1200 dpi, this page (typical of other Zope pages) requires about 1100 of those horizontal pixels to avoid scrolling EVERY SINGLE FRIGGING LINE! It's a tutorial and a HOWTO... but it takes up so much of my desktop I spend the entire experience flipping between windows, WHY on a 19" monitor at 1600x1200 am I forced to do this??? (Gerrr!) 2. Not to mention VISUAL ALACRITY! Where's the color, the captivating use of fonts, eye catching graphic highlights, nicely styled paragraphs, hypertext references, perhaps even an animated image or two?... Right, right... it's 1.1 CMF... as if THAT'S AN EXCUSE? And get this... THIS IS CLASSIC... Scroll down to Table 05.01 for a demonstration on just what it takes to modify a CMF color... Need I say more? If it were 1995 I would expect this, but the world has moved on. What... it's the author's responsibility? Go start MS Word, load any one of their templates, type "I am just a data source" and press PRINT! Does this exercise light any bulbs??? If _I_ wrote Zope... I would be sending the above author MY APOLOGIES for what I've done to their work - how many of YOU reading this page would feel either PRIDE in the presentation or would be willing to BLAME ITS AUTHOR!?! This was sent to me privately: "the issue you are talking about has _nothing_ to do with zope". What? Nothing to do with Zope? My apologies then... Let's just blame the user, the author, very convenient, very helpful, and very bound to improve Zope as a Web Publishing Platform. -Ron oh... Sorry again, Simon, for posting this on your dime... ;-/