What you see in VSD is only an "APPROXIMATION" of what your site "MAY" look like once you upload. There really is no such thing as a true WYSIWYG program anymore. This is because each operating system and browser renderes text a bit differently.

This article here at http://www.coffeecup.com/help/articles/ … -im-using/ explains why.

Oh, I'm fully aware of the rendering differences in the browsers. The frustration is that prior to build 24 my websites were all rendering fine in IE, Firefox, Safari and Chrome,...WYSIWYG.

I just finished "adjusting" all the text placement in a second site and still have to get to the text intensive ones. I'll eventually get them all done as it's necessary to make incremental changes. It appears though as soon as I open any site generated prior to build 24 It will be necessary to make adjustments to the text placement.

There probably won't be any problems with anything I start from here on out, until a similar update arrives.

It's now an annoyance rather than a problem. It's not catastrophic.

Scott, no personal offense but line breaks to an approximation is not acceptable for page rendering in VSD. I had been told the same thing when complaining about the vertical alignment of text in separate text boxes on the same page. The text baselines do not always line up across columns.

I noticed this new line break problem in Build 22 and thought updating to build 24 would resolve the problem. It does not.

Prior to coming to the forums to see if it was "just me", I changed fonts, removed links, and readjusted column sizes. Internet Explorer, FireFox, and Chrome all display the page rendering as I expect it would because they are following the line breaks generated by VSD. The page in those three browsers are identically wrong (both vertically and horizontally).

I don't have time to build websites to an approximation, jumping back and forth to see if everything aligns as expected.

I am hoping these two problems will be given some programming attention and resolved.

Robert, I can definitely understand your frustration, however what you see in build 24 is most likely as good as it is going to get. We have really tweaked the code in every conceivable way to maximize how your site rendered in all browsers.

Each time we adjust it a bit more, there is always a give and take to what the end result will be. Where we are at now is what we have found to be the best end result for the majority of our customers. Any further tweaking will most likely have more negative impact then a positive one.

As to line breaks, you can minimize those by following the instructions here:

http://www.coffeecup.com/help/articles/ … ?locale=en

Scott,

Yes, I had reviewed the page(s) in several links regarding this issue. In order that you know, I come from the "old school" of typesetting and graphic design where the individual letters were based upon an 18-unit (later a 54 unit) counting system. Analog and digital fonts were designed upon this system and each individual font contained a "width table." Those width tables were loaded into the page layout programs and the typesetting machine. This carried the horizontal width information for every printable character in the font. (I suspect you already know this, but I also believe many people do not.)

Rendering a "Line Of Type" was a precise mathematical computation of the number of characters that could be packed onto the desired line length. There were many (horizontal) spacing controls available to the operator; letter spacing, kerning, tracking, etc. It appears all this technology has been thrown out the window in the newer web based composing systems. I have not found any substance that reveals how these modern systems calculate and render lines of type.

It appears Adobe has abandoned the idea of precise character width tables in preference to "copy fitting" based upon an average number of characters that can be fit into a given line length. (Last paragraph, here: http://www.adobe.com/type/topics/info2.html) That's a pity, because if this is the basis of all "modern" systems, it is understandable that a program will only create an approximation of the copy fitting.

All of the above set aside, a user already mentioned the "real" issue. That is the text is overrunning the text box definition. If the VSD flowed text will not honor the boundaries of the text box, this is a different issue than the actual lines breaks themselves, although I suspect it's inter-related.

So the real question comes down to this: Why is VSD ignoring its own text box definition?

Without getting too technical on how the program was engineered, it is more or less just a limitation we have in the core of the program that is not easily solvable at this time. Maybe someday, but probably not anytime soon.

Okay, understood.

IMO, there definitely was a regression in how the program manages text and text boxes somewhere between Build 18 and Build 24. The text never overflowed the right side as it does now.

We can leave it at that and hope this function can be "tightened up" sometime in the future.

If anyone is following this thread and is looking for a work-around, here's what I have done...

After my text is flowed into the text box in VSD, I adjust the text box width (420 units in my case) to get the line length and VSD generated line breaks I want.

Next, I go into the text box and edit the text. I insert a space and a "hard return" (Enter Key) at the end of each line. Now when I preview the webpage, the lines break at the place where I manually entered the hard returns.

The downside of this method is if you decide to reflow the text (change the text box width, text size, font, etc.) you have to manually remove each hard coded line ending and repeat the process. But at least the VSD and the browser rendered page now consistently show the same line breaks.

I know it's not recommended and I usually tell users to remove hard turns when text over shoots its boundaries but I do have some on my site that is code pasted right from web page source code and it renders exactly how it appears in VSD. I would now recommend what ever works and looks good to you in most browsers.

I have to agree with you, I have about 7 different web projects and I hate the though of having to do an updates on the sites as I do on a regular basis. my terms page is the worst as this page as absolutely loads of text on. as you said yourself on previous versions it has always been fine but now this seems to be a backwards step...

I hate to sound negative on this subject especially as I know the Coffeecup team work really hard but this has not been a good time for me with coffeecup..