MozillaZine

SeaMonkey 2.0.2 Composer is MUCH too large

User Help for Seamonkey and Mozilla Suite
R.N. Folsom
 
Posts: 583
Joined: July 24th, 2004, 4:52 pm

Post Posted February 5th, 2010, 12:25 am

While we are waiting for KompoZer to replace SeaMonkey's Composer, Composer has been very useful to me. I use it often (roughly every other day) to edit downloaded financial and public policy analyses: I delete material that is extraneous to me --- not only content, but also extraneous links, advertisements, etc. --- and then reformat the results.

But that was in SeaMonkey 1.1.18. In SeaMonkey 2.0.2, Composer's size has ballooned to where it is unusable. Judging by the horizontal slider, a web page in 2.0.2 Composer is about a third wider than the screen, because the graphics and text both are huge. And there is no way to shrink it: The View menu has nothing about font sizes, and although the Format menu, Size, has Smaller Ctrl+-, Larger Ctrl++, x-small, small, medium, large, x-large, and xx-large, none of these work: the setting is stuck on medium; nothing else can be selected.
And in Edit, Preferences, Composer, there's nothing about font sizes.

The probable reason that in SeaMonkey 2.0.2 Composer is so large is that I work on a laptop with a 15-inch UXGA screen (1600 x 1200 pixels), so the Win2kSp4 default font setting of 96dpi makes everything that Windows controls (e.g. the start menu, Windows Explorer, Windows tab labels, etc.) much too small to read comfortably. (Lots of pixels in a small area results in very small characters.) So right-clicking the desktop, and selecting Display Properties, Settings tab, Advanced button, lets me enlarge the Windows default system font. So like many people with a UXGA screen laptop, I have increased the Windows default system font size to 144dpi (150% of the standard 96dpi), which gives a Windows default system font size about equal to the font size of an old 12" SVGA (800 x 600) 96dpi laptop screen. Still small, but comfortable to read.

But apparently, SeaMonkey 2.0.2 is much more sensitive to that 150% 144dpi setting than SeaMonkey 1.1.18 is, because initially, everything in SeaMonkey 2.0.2 is much larger than it was in 1.1.18. But aside from Composer, I've been able to shrink everything in SeaMonkey 2.0.2 as much as I needed. (My NoSquint default primary zoom level is set to 75%.) But I cannot shrink Composer 2.0.2. Even the toolbar settings that work throughout SeaMonkey 2.0.2 (Icons, Text, Icons and text, Use small icons, Show text beside icon, Use default settings) don't work in Composer 2.0.2.

Given that KompoZer is coming, I understand why no one would want to do anything to improve Composer (although I'm disappointed that no one has done the small things, since KompoZer has been a long time coming, and may still be a long time away). But is there any way to reduce SeaMonkey 2.0.2's reaction to the Windows default system font setting? If so, could that be proposed as a Bug fix?

After spending more than two weeks of full-time effort learning about SeaMonkey 2.0.2 and how to "clean" install it, and how to customize it, and writing about it (mostly questions but some answers; see my recent threads and posts in this SeaMonkey Support forum), I don't want to revert to SeaMonkey 1.1.18 simply to be able to use its Composer!

Is there any possibility that one of the third-party SeaMonkey 2.0.2 themes, such as Nautipolis, LittleMonkey, EarlyBlue, or Classic Default, would reduce SeaMonkey's sensitivity to Windows default system font setting? Or are themes simply different colors and different icons, with no substantive effects on SeaMonkey 2.0.2's behavior?

I'd very much appreciate any comments, suggestions, or help.

Roger Folsom

turu

User avatar
 
Posts: 365
Joined: August 25th, 2009, 5:27 am

Post Posted February 5th, 2010, 12:50 am

I think there are not so many differences between composer on 1.1.18 and 2.0 except icons, and if you want 1.1.x looks GUI on 2.0, try changing theme to "Seamonkey Modern".

btw, I noticed that I can't use "customize" option on Composer or Address book on SM2. Is this bug ?

R.N. Folsom
 
Posts: 583
Joined: July 24th, 2004, 4:52 pm

Post Posted February 5th, 2010, 12:32 pm

turu wrote:I think there are not so many differences between composer on 1.1.18 and 2.0 except icons, and if you want 1.1.x looks GUI on 2.0, try changing theme to "Seamonkey Modern".

Turu: Thanks for the suggestion, and I tried it, but Composer still is the same size: much too big to fit on my laptop screen.

btw, I noticed that I can't use "customize" option on Composer or Address book on SM2. Is this bug ?

Definitely yes, I think. That you can't customize or re-size anything on Composer reflects the fact that no one is updating it because they expect that someday, real soon now, KompoZer will replace Composer, but that you can't customize the Address book toolbar which, to the best of my knowledge, is not going to be replaced by anything definitely should re reported in Bugzilla.

But before doing that you're supposed to search to see if someone has already reported it, and I don't know how to do that.

Roger Folsom

Pim

User avatar
 
Posts: 2206
Joined: May 17th, 2004, 2:04 pm
Location: Netherlands

Post Posted February 7th, 2010, 12:37 pm

R.N. Folsom wrote:Judging by the horizontal slider, a web page in 2.0.2 Composer is about a third wider than the screen, because the graphics and text both are huge.

I don't get this bit. Are you saying that even if you open a new, blank, Composer window, you already have a horizontal scrollbar? You shouldn't have.
Groetjes, Pim

R.N. Folsom
 
Posts: 583
Joined: July 24th, 2004, 4:52 pm

Post Posted February 7th, 2010, 4:26 pm

Pim wrote:
R.N. Folsom wrote:Judging by the horizontal slider, a web page in 2.0.2 Composer is about a third wider than the screen, because the graphics and text both are huge.

I don't get this bit. Are you saying that even if you open a new, blank, Composer window, you already have a horizontal scrollbar? You shouldn't have.

Pim: My apologies for my sloppy wording. But before I clarify that, please note that there is some good news at the end of this post.

I am NOT saying that in a blank Composer window, I have a horizontal scrollbar. You are right that a blank Composer window does not have a horizontal scrollbar, and in fact I do not have one.

However, in SM 2.0.2 Composer --- even if its window is maximized to use all of my laptop's screen --- if I open a previously downloaded and saved web page from the internet, it may not fit because the document is too wide. (Some web pages do fit because they're not too wide). My test file's graphics are very large, and its text is roughly xx-large (in the Format > Size menu if I were writing a new document), although with the document opened the Format > Size menu says its font size is only medium. I have not been able to find any way to reduce the document's size so that its width fits in Composer.

In contrast, in SM 1.1.18 Composer, I never had a problem with web pages not fitting. My recollection is that they always fit, and that I'd never seen a horizontal scrollbar (in SM 1.x Composer). But even if that recollection is wrong, I know that the test file I describe in my preceding paragraph DID fit in 1.1.18 Composer. (And that test file is from a financial newsletter, whose web pages --- all of which follow the same format --- I frequently save and then use Composer to edit.)

Moreover, this morning I ran an experiment. As I explained in my message that started this thread (see the third paragraph), on my 15-inch screen UXGA laptop, my standard Windows system font setting is 144dpi (150% of the standard 96dpi). This morning I reduced it to 120 dpi (125% of the standard 96dpi), and opened 2.0.2 Composer. It took up roughly only 25% of the screen (i.e. the upper left corner). And after I widened the Composer screen a bit, my test document fit with absolutely no problem.

And SeaMonkey 2.0.2 itself (browser and email) also used only the upper left corner of the screen.

To me, that confirms that SeaMonkey 2.0.2 is much too sensitive to a 150% Windows system font size.

Unfortunately, in Windows 2000 (but not in XP, I think, but I'm not willing to take the time to make that switch unless Eset's NOD32 antivirus stops supporting Win2k), a change in the Windows system font size requires a reboot, so reducing its setting from 144dpi to 120dpi isn't a practical routine workaround. (The reduction from 144dpi to 120dpi is only a 17% reduction based on 144dpi, or 20% based on 120dpi, but 120dpi for everyday use isn't visually practical, because 144dpi itself is fairly small, although much blacker than 120dpi. I would expect people with visually impaired vision would use 175% or 200%.)

In other news: I tried all of the alternate SeaMonkey 2 themes I could find --- SeaMonkey Modern, Classic Default, EarlyBlue, LittleMonkey, Nautipolis, Schellen Pinball and GrayModern, but none of them solved the Composer problem.

Good News, although not perfectly good news:

In my initial post, I said that the "Format menu, Size, has Smaller Ctrl+-, Larger Ctrl++, x-small, small, medium, large, x-large, and xx-large, none of these work: the setting is stuck on medium; nothing else can be selected." I've since discovered that to be wrong --- those font size settings do work --- if Composer is starting with a blank page.

And those font size settings work also if Composer is NOT working with a blank page, for example if my test file is loaded. In that case, those font size settings work on anything that is selected, which can be everything (i.e. Ctrl-A).

But that news still isn't perfect, because even after selecting everything and shrinking the font size down to x-small, my test web page still doesn't fit, because (of course) shrinking the text does nothing to shrink the graphics, which in my test file are quite large because the opening icon uses the entire width of the page (apparently to make room for some links within the opening icon). So even after shrinking the fonts, the page itself is too wide to fit --- it's just as wide as it was in the first place --- and still needs a horizontal scrollbar.

SeaMonkey 2.0.2's ability to shrink (or expand) graphics as well as fonts apparently doesn't extend to the 2.0.2 composer. (And as others have noticed, Composer's toolbars cannot be customized, even to use small icons instead of the standard size icons that, in 2.0.2 on my 150% 144dpi laptop, are enormous.)

A possible workaround, with which I may find time to experiment with today but more likely next weekend, is to shrink a downloaded and saved webpage --- graphics as well as text --- before loading it into Composer.

Roger Folsom

Pim

User avatar
 
Posts: 2206
Joined: May 17th, 2004, 2:04 pm
Location: Netherlands

Post Posted February 8th, 2010, 12:58 am

Just a hunch. Did you make SeaMonkey 2 inherit the profile from SM 1.1?
If so, could you check the about:config screen for these settings:

browser.screen_resolution
browser.display.screen_resolution
layout.css.dpi

The top one is what it was called in the Mozilla Suite. The next one in SM 1.1, and the last one is how it's called now.
If these settings are not there, it's OK. No need to add them. For the ones that are there, however, make sure they all have the same value of 144.

NoSquint may be confusing matters too. Are you sure that this behaviour was already there before you installed NoSquint? It's possible that SeaMonkey itself thinks that it needs to make the icons larger, and then NoSquint makes them larger again. Or is that not how it works? I'm not familiar with NoSquint.

By the way, even in Windows Vista does a change in display DPI require a reboot. The philosophy being that you change that setting once, to match the physical properties of the monitor, and then you leave it as is. Changes in DPI imply changes in hardware.
Groetjes, Pim

Andy Boze

User avatar
 
Posts: 2755
Joined: June 30th, 2005, 9:53 pm
Location: South Bend, IN

Post Posted February 8th, 2010, 3:21 pm

Pim wrote:If so, could you check the about:config screen for these settings:

browser.screen_resolution
browser.display.screen_resolution
layout.css.dpi

Unfortunately those preferences have an effect only in non-Windows OSes. See http://kb.mozillazine.org/Layout.css.dpi. You might try layout.css.devPixelsPerPx set at an integer value of 1.
But then again, I may be wrong.

R.N. Folsom
 
Posts: 583
Joined: July 24th, 2004, 4:52 pm

Post Posted February 8th, 2010, 10:51 pm

Pim wrote:Just a hunch. Did you make SeaMonkey 2 inherit the profile from SM 1.1?
If so, could you check the about:config screen for these settings:
browser.screen_resolution
browser.display.screen_resolution
layout.css.dpi
The top one is what it was called in the Mozilla Suite. The next one in SM 1.1, and the last one is how it's called now.
If these settings are not there, it's OK. No need to add them. For the ones that are there, however, make sure they all have the same value of 144.

Pim:
Before installing SM2, I had already uninstalled SM1, and done a pretty thorough job of cleaning the Windows registry of SM1 residue. But I did have my SM1 profile on my data partition D, and in C:\Administrator\Application Data\Mozilla a SM1 registry.dat remained, which could tell SM2 where to find my SM1 profile on partition D.

After installing SM2, the first time I ran it of course it offered to migrate "everything" from my SM1 profile, but I told it NOT to do so because I wanted a clean install of SM2.

Instead, I imported some things (e.g. bookmarks and my address book) and copied others (e.g. my mail folders) --- unfortunately I found no way to transfer my passwords, so I'm gradually adding passwords to signons.sqlite.
Basically, I flailed around. I did rely a lot on "Transferring data to a new profile - SeaMonkey" (http://kb.mozillazine.org/Transferring_ ... _SeaMonkey).
For my flailing, see "Selective Migration To 2.0.2 From 1.1.18" (viewtopic.php?f=40&t=1707465)
For a more coherent explanation of what I did, see "SM2 Profiles Into Non-Default Locations, Part-1" (viewtopic.php?f=40&t=1718355). Part-2 is the second message in the thread.

NoSquint may be confusing matters too. Are you sure that this behaviour was already there before you installed NoSquint? It's possible that SeaMonkey itself thinks that it needs to make the icons larger, and then NoSquint makes them larger again. Or is that not how it works? I'm not familiar with NoSquint.

Unfortunately, NoSquint has no effect on Composer. But it does have an effect on actual websites, such as MozillaZine, so I disabled it, exited SeaMonkey so that the NoSquint disable takes effect, and have now returned to SeaMonkey.

Contrary to Andy Boze's post (more on that in my message to him), I found that in SeaMonkey 2.0.2 layout.css.dpi has a substantial effect on SeaMonkey browser, some effect on email and address book, and strong effect on Composer. The original value was -1. Starting with 96 dpi, I tried 120, 135, 140, 143, and 144, and 150. With everything up to and including 143, fonts and the Composer window started out small and got bigger. But the jump from 143 to 144 was enormous, I think because the print got thicker and therefore darker (my guess is that lines jumped from one to two pixels thick). And that one point increase caused Composer to lock up into an essentially full screen position, and as soon as I opened a file for editing the window couldn't hold the full width of text and side-links.

You could live with 143dpi, but 144 is a lot easier to read. Amazing.
[Edit: The jump between 143dpi and 144dpi apparently is due to lines getting two pixels. See my next message to Andy Boze.]

By the way, even in Windows Vista does a change in display DPI require a reboot. The philosophy being that you change that setting once, to match the physical properties of the monitor, and then you leave it as is. Changes in DPI imply changes in hardware.

That's interesting. But given the multi-year differences between Win2k and Vista, there may be a difference between changing Vista's "display DPI" and Win2k's "system font size." Someone familiar with XP, with which I have absolutely no experience, probably could clarify whether XP can change "system font size" without a reboot, assuming that XP has a setting similar to Windows.

Thanks very much for inviting my attention to those About:config settings. I also looked for a Composer setting, and found intl.charsetmenu.composer.cache;ISO-8859-1, UTF-8. Nothing about font or graphics sizes.

Roger Folsom
Last edited by R.N. Folsom on February 9th, 2010, 1:21 am, edited 1 time in total.

R.N. Folsom
 
Posts: 583
Joined: July 24th, 2004, 4:52 pm

Post Posted February 9th, 2010, 1:15 am

Andy Boze wrote:Unfortunately those preferences [e.g. layout.css.dpi] have an effect only in non-Windows OSes. See http://kb.mozillazine.org/Layout.css.dpi. You might try layout.css.devPixelsPerPx set at an integer value of 1.

Andy: Two points.

1) I'm not sure that MozillaZine Layout.css.dpi article is up-to-date re SeaMonkey 2.0 (more precisely, 2.0.2), because --- as I describe in my immediately preceding post to Pim --- in my SM 2.0.2, About:config Layout.css.dpi does have an affect on SeaMonkey 2.0.2 font sizes.

The MozillaZine Layout.css.dpi article may not have been fully aware of SeaMonkey 2.0.2's changes.

Under Caveats, the article notes that "This preference is not present by default on Windows," which at least allows for the possibility that somebody could figure out how to add this preference into Windows versions of SeaMonkey.

On the other hand, the article says that Layout.css.dpi "Has an effect in Firefox (all non-Windows versions since 2.0), Thunderbird (all non-Windows versions since 2.0), and SeaMonkey (all non-Windows versions since 1.1)" --- but a linguist could argue that those statements about non-windows versions don't preclude Layout.css.dpi from having an effect in Windows versions also.

Finally, the article says that "This page was last modified 02:51, 24 April 2009." I don't know when SM 2.0 first came out, but I doubt it was a lot earlier than when the "page was last modified."

2) Much more important: layout.css.devPixelsPerPx 1 (the initial setting was -1) solved the unworkable Composer problem, apparently regardless whether Layout.css.dpi was set to -1, some integer less than 144 dpi, or some integer equal to or larger than 144 dpi. I don't know what the "dev" means, or what "Px" means, but a setting of 1 apparently forces not only font lines to be no wider than one pixel, but also lines used in icons. So the excessively large icons that were in Bookmarks (until you showed me how to remove them), File Bookmarks, Manage Bookmarks, and Mail lists now are almost too small, and the "double spacing" of lists is history. And even if my userChrome.css is disabled (so that the 9 point setting is bypassed), Mail & Newsgroups Account Settings, Server settings, now has plenty of room for the Local Directory field --- even when, as an experiment, I set Layout.css.dpi to 150.

I can prevent default font sizes from being too small by using Layout.css.dpi and/or the default font size setting in userChrome. At the moment those are 144dpi and 9.5 points, respectively. I'll do a little experimenting, because now my SeaMonkey browser tabs labels are unnecessarily short (i.e. hiding some information about what's in the tab) while they used to use all the available space, i.e. two tabs open would have long labels which shortened only if I opened another tab.

But the big problems all are gone. (However, if your curiosity ever discovers how to remove icons from File Bookmarks, Manage Bookmarks, Mail folders, but not mail lists which need flag and attachment icons, I'd be very much interested in how you do that, even though now it isn't necessary for me.)

Once again, thank you very much for all the helpl

Roger Folsom

Andy Boze

User avatar
 
Posts: 2755
Joined: June 30th, 2005, 9:53 pm
Location: South Bend, IN

Post Posted February 9th, 2010, 11:27 pm

That's interesting about the layout.css.dpi preference. I had actually set my screen resolution to 144 dpi before trying it. It had no effect on SeaMonkey or Firefox, so I assumed the article was correct. Of course, I tried setting layout.css.dpi before I added the layout.css.devPixelsPerPx preference, which was absent in about:config. It seems that there's some interaction between the two preferences. After I saw your post, I tried it again, and it did make a difference

I've not been able to find any real documentation about layout.css.devPixelsPerPx. I assume it has to do with device pixels in relation to rendered pixels
But then again, I may be wrong.

Pim

User avatar
 
Posts: 2206
Joined: May 17th, 2004, 2:04 pm
Location: Netherlands

Post Posted February 10th, 2010, 8:57 am

My assumption too, although I wonder why, if it means "device pixels", there is no similar specification for different devices, like the printer.

If -1 means: use the values that the OS provides, I wonder if 1 doesn't mean always to use 1:1 translation.

In other words, now that it's set to 1, wouldn't SeaMonkey print 100 pixels as 100 printer dots?
Groetjes, Pim

R.N. Folsom
 
Posts: 583
Joined: July 24th, 2004, 4:52 pm

Post Posted February 10th, 2010, 2:39 pm

Andy Boze wrote:That's interesting about the layout.css.dpi preference. [RNF: In Windows,] I had actually set my screen resolution to 144 dpi before trying it. [RNF: "it" being Layout.css.dpi = 144?]. It had no effect on SeaMonkey or Firefox, so I assumed the article was correct. Of course, I tried setting layout.css.dpi before I added the layout.css.devPixelsPerPx preference, which was absent in about:config. [RNF: The layout.css.devPixelsPerPx preference was already in my SeaMonkey 2.0.2 about:config.] It seems that there's some interaction between the two preferences. After I saw your post, I tried it again, and it did make a difference.]

Andy: If you temporarily disable layout.css.devPixelsPerPx by setting it to -1, and then try some different numbers for Layout.css.dpi, I think you'll be able to replicate my results, even though I'm using Win2kSp4 rather than whatever OS a high tech geek like you <grin> is using.

The amazing thing to me about layout.css.devPixelsPerPx = 1 is that, apparently, it affects icons as well as text (unless it was the Layout.css.dpi = 144 that did that, but I think I would have noticed the much smaller icons when I had Layout.css.dpi = 144 prior to setting layout.css.devPixelsPerPx = 1).

If you try layout.css.devPixelsPerPx = 2 you'll get some truly "interesting" results.

I've not been able to find any real documentation about layout.css.devPixelsPerPx. I assume it has to do with device pixels in relation to rendered pixels

What do you mean by "device" pixels, vice "rendered" pixels? I could use a description of an example or two of each.

Roger Folsom
Last edited by R.N. Folsom on February 10th, 2010, 3:19 pm, edited 1 time in total.

R.N. Folsom
 
Posts: 583
Joined: July 24th, 2004, 4:52 pm

Post Posted February 10th, 2010, 3:10 pm

Pim wrote:. . . If -1 means: use the values that the OS provides, I wonder if 1 doesn't mean always to use 1:1 translation.

Pim:

I don't think that layout.css.devPixelsPerPx = 1 means use the OS values at all. I think it means that whatever fonts and icons SeaMonkey uses, nothing --- a number, character, or graphic (perhaps graphic boundaries) --- can have lines more than one pixel in width.

"But then again, I may be wrong." I must have seen that somewhere recently.... <grin>

Roger Folsom

P.S.: Since my problems that arose with SM2 had never occurred with SM1, I'm wondering how much difference there is between SM2 and SM1 user interface fonts. But I don't know where they are located, or (more likely) where SeaMonkey calls on fonts already installed on the computer.

If you compare icons, you'll notice that the SM2 icon names are identical to the SM1 icons (except that SM2 adds ablistWindow.ico and venkman-window.ico, which do I know not what), but that the majority of SM2 icon files --- those file sizes are 133kb or 125kb --- are much larger than their SM1 counterparts. And oddly for icon files, their file icon doesn't match what they actually display (using Irfanview). A few SM2 icons are only 25kb, and those appear to be identical to their SM1 counterparts.

So what? I dunno.

Philip Chee

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted February 10th, 2010, 10:01 pm

R.N. Folsom wrote:
btw, I noticed that I can't use "customize" option on Composer or Address book on SM2. Is this bug ?

Definitely yes, I think. That you can't customize or re-size anything on Composer reflects the fact that no one is updating it because they expect that someday, real soon now, KompoZer will replace Composer, but that you can't customize the Address book toolbar which, to the best of my knowledge, is not going to be replaced by anything definitely should re reported in Bugzilla.

Well the reason I haven't added Customizable Toolbars to the Composer or the Address book components is that I'm stuck with needing suitable images for the new (movable) big and small buttons. For classic this isn't too bad because I can just take the existing images and resize them. However, the modern images are just not suitable for customizable toolbars and no amount of resizing will change that. Unfortunately I don't have any graphic design skills so I'm stuck. :?

R.N. Folsom
 
Posts: 583
Joined: July 24th, 2004, 4:52 pm

Post Posted February 11th, 2010, 3:58 pm

Philip Chee wrote:Well the reason I haven't added Customizable Toolbars to the Composer or the Address book components is that I'm stuck with needing suitable images for the new (movable) big and small buttons. For classic this isn't too bad because I can just take the existing images and resize them. However, the modern images are just not suitable for customizable toolbars and no amount of resizing will change that. Unfortunately I don't have any graphic design skills so I'm stuck. :?

Thanks very much for that explanation! You've solved two mysteries: First, why the Composer and Address Book toolbars aren't customizable; second, why the new icon files (in C:\Program Files\SeaMonkey\chrome\icons\default) are as huge as they are. I gather that their huge size is because they are customizable --- perhaps because each file includes two images (one large and one small), as well as switching code?

I gather also that you can't "borrow" SeaMonkey 1.x Composer and Address book icons to use in SM 2.x because there's a policy that insists that throughout SeaMonkey 2.x the icons all must be visually appealing in a consistent way.

I'd vote for functionality rather than beauty, but I'm an odd duck in that department (as I've seen in https://bugzilla.mozilla.org/show_bug.cgi?id=513691).

Roger Folsom

Return to SeaMonkey Support


Who is online

Users browsing this forum: No registered users and 2 guests