New Foswiki release 2.1.6 is available with important security fixes.
Sourceforge foswiki email lists being discontinued. Subscribe to the new Foswiki announce and discuss lists at MailingLists
You are here: Foswiki>Tasks Web>Item12351 (01 Feb 2013, GeorgeClark)Edit Attach

Item12351: Upgrading from 1.1.5 to 1.1.6/1.1.7 destroys users topic layouts because of font size change

Priority: Urgent
Current State: Closed
Released In: 1.1.7
Target Release: patch
Applies To: Extension
Component: PatternSkin
Branches: Release01x01
Reported By: KennethLavrsen
Waiting For: ArthurClemens, KennethLavrsen
Last Change By: GeorgeClark
I recently tried to upgrade our office Foswiki from 1.1.5 to 1.1.6.

I had to give up.

First I had some issues related to details around the upgrade itself. That was annoying but if I had read the instruction of the download page and the release note I would have known.

But when I finally had it running I noticed that text fonts had increased in size??!!

So I started checking some of the important topics that are used by many people. This includes vital wiki applications that present information in tables.

And to my horror I see that the tables people have tweaked with TABLE columnwidth settings are screwed. It is 1000s of topics that have problems.

How could anyone make skin changes in a patch release? Why this small font change?

There are also other changes done to the skin that should not have been done in a patch release. But the font increase the the serious one because it destroys presentation of content every where.

Imagine if Microsoft sent out a security update to Powerpoint that increased all fonts by 5%.

We need the font back to where it was. I don't know where to begin to hack the skin to fix my immediate need so I reverted back to 1.1.5 and I am not beta testing 1.1.7 for the same reason

-- KennethLavrsen - 17 Jan 2013

How about a screenshot before-after?

-- MichaelDaum - 17 Jan 2013


These are the types of things that just don't jump out at me as issues during the release process, and are why we have alpha, beta RC leading to a release. I need this type of help leading up to the release. Anyway, what's done is done. Now to fix. it.

I'm debating making this a blocker for 1.1.7. I really wanted to get 1.1.7 out to get the CVE addressed in a release.

(If the reason to not beta test is because you found a problem in the release. Then what you get in the release is what you get. Beta / RC testing is your chance to find this stuff. I'm a bit stumped on what to say. Thanks for your help?)

Arthur, can you address this.

-- GeorgeClark - 17 Jan 2013

I can beta test all by myself but I cannot do what I did in previous years, upgrade the production site. I cannot even upgrade it to 1.1.6. That is what I mean.

I don't think anyone needs screenshots to know that a larger font inside a table where columnwidths are given in pixels is a problem.

It is not the headline sizes or UI sizes that is the problem. It is the size of plain text that causes the trouble.

I was hoping the one that made the change could get the plain text reverted back to what it was

When upgrading to a 1.2 or 2.0 I will expect some time to upgrade, but in a patch release we admins are supposed to be able to just apply the upgrade package without waking up to major skin changes. Patch releases are for bug fixes.

-- KennethLavrsen - 17 Jan 2013

Probably not the right place to discuss ... but as I feel my way through the release process, things like this need to be covered in the Sanity tests. In TestCaseTablePlugin would you be able to contrive a table with a "This should not wrap" column or columns. Or is this also browser dependent.

Arthur has not been around on IRC for a couple of months now, so not sure if he will be able to look at this for us. I could probably start reverting things, but we'd be a lot better off if we could pick up stuff like this sooner than later. There have been complaints about readability of pattern skin, I'm not sure the size changed, vs a font change that renders differently.

-- GeorgeClark - 18 Jan 2013

I think this gets it a lot closer. There have been extensive css changes, but the following helps. I believe generally they were related to consistency across browser platforms. There were a lot of changes to get better consistent styling in buttons, etc. Also adding / improving HTML5 compatibility. Could you see if the below patch at least resolves the table layout issues.

Another thought, could we take the 1.1.5 css and create a PatternSkinTheme115? Maybe not. I pulled over 1.1.5's PatternSkinTheme as a new theme, and it looks much smaller than 1.1.5. So unless the below is sufficient, I guess we need Arthur's help.

diff --git a/PatternSkin/pub/System/PatternSkinTheme/style_src.css b/PatternSkin/pub/System/PatternSkinTheme/style_src.css
index 5f182e8..9232c47 100755
--- a/PatternSkin/pub/System/PatternSkinTheme/style_src.css
+++ b/PatternSkin/pub/System/PatternSkinTheme/style_src.css
@@ -400,8 +400,8 @@ table {
 html body {
-       font-family: sans-serif;
-       font-size: 14px;
+    font-family: arial,verdana,sans-serif;
+    font-size: small;
 body {
        line-height: 22px;

-- GeorgeClark - 18 Jan 2013

Kenneth, do you still see a chance to get a screenshot of those tables that now are "destroyed" based on font size differences? This is hard to get by guessing what you actually mean. See, talking about web design without screenshots or any other visual feedback is like listening to porn on the radio.

-- MichaelDaum - 18 Jan 2013

Porn on the radio. We cannot have that. The main issue is that topics with tables where people have adjusted table widths to the text they have written are wrapping the text around looking ugly.

These tables are used to present to senior management and used in weekly hotline emails etc. It would be impossible for me in practical to increase table widths by 10-20 pixels everywhere. We have to trust that the content in the topics does not change just because I apply a small bug fix release.

I have attached an example of a table. I had to alter the text because the content is confidential (our business plans) but I have made a typical example taking some actual milestone texts and actual tables.

To the left the 1.1.7 (yes George - I have a 1.1.7 running in parallel - that only few know about) and to the right the 1.1.5 (security patched).

Our need is to get the plain text font back to what it was in size so the same amount of ems fit into the same amount of columnwidth expressed in pixels.

-- KennethLavrsen - 18 Jan 2013

Note that image attached is a bit large so I attached it without showing it in this topic.

Here is the table that I use

Milestone PlannedSorted ascending Forecast/Actual Status
Technical Requirements Document Released
28 Sep 2012
28 Sep 2012
Technical Requirements Document Reviewed
05 Oct 2012
12 Oct 2012
Technical Architecture Document Released
19 Oct 2012
09 Nov 2012
Technical Architecture Document Reviewed
26 Oct 2012
20 Nov 2012
Program Kickoff
30 Oct 2012
02 Nov 2012
Engineering Authorization
30 Oct 2012
30 Oct 2012
Program Authorization
30 Oct 2012
02 Nov 2012
Requirement and Architecture Complete
02 Nov 2012
05 Jan 2012
Implentation Authorization
16 Jan 2013
25 Jan 2013
Small Delay
Ready For System Test
28 Jun 2013
28 Jun 2013
Ship Acceptance Europe
22 Oct 2013
22 Oct 2013
Ship Acceptance Global
22 Nov 2013
22 Nov 2013

Note how the skin used on totally changes the layout also.

Table layouts are very skin sensitive which is why it is so difficult in a business environment to change things like a skin. It is not the UI and layout of buttons that is the issue. It is the topic content itself that is the problem.

-- KennethLavrsen - 18 Jan 2013

Just to add fuel to the fire, but the current font change seems to break configure for me. Break, as in, the "Security and Authentication" text runs over the warning signal. I would more qualify that as a separate bug than anything else, because it can happen just if the user increases the font, or has a really small screen. But still I thought it might be worth mentionning it here.

-- OlivierRaginel - 18 Jan 2013

There are two solutions to really address the problem.

(1) Add a font-size param to TABLE to make it match the column widths.

(2) Make all column width em values, not px.

The problem is that there's a hard-coded column width expressed in px which depends on a very specific font-size, 12px or so in this case. As a consequence any change of the font-size no matter how will affect word wrapping in cells. A font-size differ among browsers and user settings, different skins, web designs, etc.

-- MichaelDaum - 18 Jan 2013

I have checked George's proposed fix above and it seems to do the work that I would need to avoid 100s of people screaming of me when I upgrade.

-- KennethLavrsen - 18 Jan 2013

That's very likely to display wrong for those people that configured a different font-size value for small in their browser. Btw for those people not having Arial installed on their computer Verdana looks very different and will likely break your tables again.

-- MichaelDaum - 18 Jan 2013

The diff I posted was what's in 1.1.5 CSS. Figured it would be safest.

-- GeorgeClark - 18 Jan 2013

Now I'm very confused. I see the wrapping on this page, but uses the FatWilly theme, and that theme is using the original font-size: small; font-family: arial ... that I suggested above. so I have no idea why it is wrapping here. It's something else.

-- GeorgeClark - 18 Jan 2013

The wrapping in tables also depends on the settings for TablePlugin and the CSS for tables in the theme. That is normal. The important thing is that people can upgrade patch releases without having to spend a week adjusting and hacking. The end users are very sensitive to this kind of changes. In my company half the topics on our wiki are status topics that managers show to their managers. They create a new topic every in 20 different departments and then it ripples up the management ladder. When I test a new version of Foswiki these topics are the first I check because there is so much focus on them. And with 20 per week for 12 years it is really many topics to manually change column widths on. It is not at all the same concern if a header style changes size. It rarely makes any significant layout changes that you cannot live with.

-- KennethLavrsen - 19 Jan 2013

Previously I have made a skin theme to handle changes. Never thought that these changes would affect users that much. So what is possible is to wrap the old css into theme PatternSkinTheme2012 and use that.

-- ArthurClemens - 20 Jan 2013

Kenneth, What browser is having wordwrap issues. I've pasted your table into a test case and I get wordrap with both Firefox and Chromium on a vanilla 1.1.5 system, as well as 1.1.6 and 1.1.7. If I don't have a repeatable test case, I can't see how we can fix this for 1.1.7, and prevent further breakage in newer releases.

Could you confirm that a minimal change from:
-    font-size: 14px;
+    font-size: small;

is sufficient for your platform, or is it the font-family that is causing the issue.

-- GeorgeClark - 24 Jan 2013

I managed to get a IE8 vm running. Confirm that the changes to font-family and font-size are both required to get IE8 to not wordwrap that table. Firefox and Chromium both wrap however, so the fix is only for the one browser.

I'm going to check this in and build one more RC.

-- GeorgeClark - 24 Jan 2013


It is OK that text may wrap in other browsers. In a business environment all run Windows and all run IE as default browser. What is important is that the font size did not CHANGE for normal text so people having adjusted columnwidths in tables and other similar text layout see their topics screwed up next time they look at the topic in the same browser. There has always been differences in how things look in different browsers. And also differences how pages look in Firefox on Linux vs Windows. I can confirm that changing the text back to small does the job.

And I have also confirmed that things work fine when you change text size in the browser. You can go both up and down in zoom and get a useful result so Michael's concern is not happening in practical life in PatternSkin.

-- KennethLavrsen - 25 Jan 2013

ItemTemplate edit

Summary Upgrading from 1.1.5 to 1.1.6/1.1.7 destroys users topic layouts because of font size change
ReportedBy KennethLavrsen
Codebase 1.1.6
SVN Range
AppliesTo Extension
Component PatternSkin
Priority Urgent
CurrentState Closed
WaitingFor ArthurClemens, KennethLavrsen
Checkins distro:8dc06344a85f
TargetRelease patch
ReleasedIn 1.1.7
CheckinsOnBranches Release01x01
Release01x01Checkins distro:8dc06344a85f
Topic revision: r20 - 01 Feb 2013, GeorgeClark - This page was cached on 10 Jul 2018 - 23:07.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy