Closed Bug 102199 Opened 23 years ago Closed 23 years ago

Change after 0.9.4 made 9pt and under fonts too small

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jmd, Assigned: dbaron)

References

(
URL
)

Details

Attachments

(10 files)

image demonstrating the problems. sidebar and image caption are the most visible ones.
127.29 KB, image/png
Details
Win32 rendition of tinderbox
3.40 KB, image/gif
Details
NS_FONT_DEBUG=5
11.48 KB, text/plain
Details
NS_FONT_DEBUG=5 output with Tinderbox loaded
8.15 KB, text/plain
Details
NS_FONT_DEBUG=C output with Tinderbox loaded
10.54 KB, text/plain
Details
NS_FONT_DEBUG=C of https://system.oraclesmallbusiness.com/pages/login.jsp
13.52 KB, text/plain
Details
xlsfonts | grep -e adobe-helvetica -e 8859-1
6.28 KB, text/plain
Details
patch; prefer fonts over 8 pixels
702 bytes, patch
Details | Diff | Splinter Review
Screenshot of tinderbox WITHOUT font.minimum-size.x-western set
2.86 KB, image/png
Details
Screenshot of tinderbox WITH font.minimum-size.x-western set to 13
3.41 KB, image/png
Details 
Pages with 8 or 9pt fonts got a LOT smaller between 0.9.4 and the trunk a few
days later, and has remained so. At that URL, IE5/6 and Mozilla 0.9.4 show all
of the text (form fields, headers, the submit button) much bigger. Netscape 4.7
does to but that's probably it not parsing the CSS right.

Linux only?
What's the current story with our various minimum font size prefs?
See also bug 30910.  But what exactly should I be seeing on the testcase (other
than it not crash my browser, which it just did)?
dup of bug 84884?
> But what exactly should I be seeing on the testcase

compare font size vs. 0.9.4. 0.9.4 on linux renders it the same as IE5/6 on
windows. Post 0.9.4 trunk builds render it too small. Not just this page, any
page with 8 or 9 pt fonts.
> (other than it not crash my browser, which it just did)

Hrm, never did that for me. But unfortunatly I don't use that page much in
Mozilla, since after you log in, it's just gobs apon gobs of IE-only javascript.
Kinda shoddy coming from Oracle, I have to use it for work, though.

> dup of bug 84884?
I don't think so, that's about 0.9.1. This definatly appeared a few days after
0.9.4 branched.
It looks like it's Unix only.  I compared 2-months old trunk builds and more 
recent ones on Win98 and Mac but they don't show any difference in font size.  
The editable fields are much smaller in length (now comparable to what we have in 
IE) but that's a fix from Rod.

The fonts I'm seeing on the above URL are nowhere near tiny.  They're larger
than normal.
Confirming. Some time after 0.9.4 small fonts got even smaller, to the point of
becoming unreadable in some cases.
Has it got to do perhaps with the font changes from bug 99010? I find the text
to some URL's to be unreadable as well.
That tinderbox sidebar panel uses 'font-size: 8pt'.  Could something have broken
a minimum font-size threshhold?  rbs?
The minimum font-size limit isn't enforced by default -- it needs a pref. BTW,
Win2K is rendering the tinderbox fine, I will attach a screenshot (note: there
is a XP open issue with absolute font-sizes, e.g., <font size="-1">, c.f. bug
102805 which was filed by Mrten who also commented above, but it doesn't seem
connected to this one which is unit-related and seems to be specific to some
linuxes -- see 
bug 84884 which was recently resolved as WFM).




    
    

    
  
Actually, I remember happy times when tinderbox looked the same under Linux (I'm
using Microsoft fonts).

    
    

    
  
please the environment variable NS_FONT_DEBUG=5, do a minimal run 
(eg: ./mozilla http://some.website.com/some_content.html), capture the output,
and attach it to this bug

    
    

    
  

      
      
      
      

        Attached file
          
        NS_FONT_DEBUG=5
        — 
      

    


  

    
    

    
  
oops, could you redo this with NS_FONT_DEBUG=C


    
    

    
  
I'd guess this is the interesting part:

> outline font:______ -microsoft-verdana-medium-r-normal--%d-*-0-0-p-*-iso8859-2
>                     desired=8, scaled=8, bitmap=0, nsFontMetricsGTK.cpp 2505
> scaled font:_______ microsoft-verdana-iso8859-2
>                     desired=8, scaled=8, bitmap=0, nsFontMetricsGTK.cpp 2536

Can you try using xfd to display 
 -microsoft-verdana-medium-r-normal--8-*-0-0-p-*-iso8859-2
and see if these are the glyphs you are seeing?


    
    

    
  
Yes, I see the same unreadable font.

BTW, all this seems like replay of bug #87055.

    
    

    
  
What I see is layout asking for an 8 pixel verdana font and the font code 
supplying an 8 pixel font.

thorgal: can you check your screen resolution?
Go to:

  Edit->Preferences->Fonts->"Display Resolution"->Other

and enter the mearurement.

Then see if layout asks for a larger font.


    
    

    
  
Well, it appears to have fixed the problem. I've just checked problematic sites
(CNN.com, tinderbox) and fonts are of proper size now. Hopefully it won't break
anything else.

Thanks.

    
    

    
  
based on these comments I'm marking the bug invalid.

If you see further problem reopen as appropiate.


Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID

    
    

    
  
Er... what was the fix? I don't have any microsoft fonts. Everything is still
small in todays build.

    
    

    
  
Jeremy: could you check you screen resolution also?
If the fonts are small could you redo the output with
NS_FONT_DEBUG=C 

    
    

    
  
Re: res

Mozilla is set to use system resolution, xpdyinfo says:
  dimensions:    1152x864 pixels (390x293 millimeters)
  resolution:    75x75 dots per inch


    
    

    
  
Jeremy: I see it looking for a 9 pixel and getting an 8 pixel

Can you run this command and attacht the results:

> FindFont(a/0x0061), nsFontMetricsGTK.cpp 4046
>     FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3577
>         familyName = helvetica, nsFontMetricsGTK.cpp 3590
>         TryFamily helvetica with lang group = x-western, nsFontMetricsGTK.cpp 
3525
>       TryLangGroup lang group = x-western, aName = *-helvetica-*-*, 
> nsFontMetricsGTK.cpp 3507
>       lang group = x-western, nsFontMetricsGTK.cpp 3973
>       iso8859-1 ffre = *-helvetica-iso8859-1, nsFontMetricsGTK.cpp 4003
>         TryNodes aFFREName = *-helvetica-iso8859-1, nsFontMetricsGTK.cpp 3416
>         load font adobe-helvetica-iso8859-1, nsFontMetricsGTK.cpp 2921
> bitmap font:_______ adobe-helvetica-iso8859-1
>                     desired=9, scaled=9, bitmap=8, nsFontMetricsGTK.cpp 2530

Lets see what size fonts you have. Can you run this command and attach the 
results:

  xlsfonts | grep adobe-helvetica | grep 8859-1


    
    

    
  
From what I understand of what you pasted, and your comments, it found an 8px
font and scaled it to 9px. But the source is requesting 9 pT, not pX. And what
I'm seeing is much smaller text, not pixelated unreadable text (a la Netscape 4)
due to scaling.

If I increase text size once (CTRL+KP_PLUS), I think that's the size I used to
see in 0.9.4, and about the size I see in IE.

I'm willing to accept this may be due to crappy fonts I have installed... Linux
isn't known for its high quality fonts, especially an old version of Slackware,
but there seem to be other issues here.

    
    

    
  
> From what I understand of what you pasted, and your comments, it found an 8px
> font and scaled it to 9px. But the source is requesting 9 pT, not pX. 

No scaling happened. The layer above the font subsystem asked for a 9 pixel
font. Point to pixel is handled above the font subsystem. The font subsystem
found the nearest font to be 8 pixel.  Your font list shows 8 and 10 pixel
fonts but no 9 pixel font. In the case of a tie it picks the smaller font.
That code has been in place since May 2000.

> what I'm seeing is much smaller text, not pixelated unreadable text (a la 
> Netscape 4) due to scaling.

The font subsystem appears to be doing as requested within the bounds of 
what it has to work with.

> If I increase text size once (CTRL+KP_PLUS), I think that's the size I used 
> to see in 0.9.4, and about the size I see in IE.

What size (point/pixel) is the page requesting?


    
    

    
  
When I said source in my previous comment, I meant page source, not Mozilla
source. It's requesting 9 pt. Mozilla is rendering with what appears to be an 8
PIXEL font.

    
    

    
  
> Mozilla is set to use system resolution, xpdyinfo says:
>  dimensions:    1152x864 pixels (390x293 millimeters)
>  resolution:    75x75 dots per inch

A 9 point font on a 75 DPI system would be 9 pixel which is what layout
is requesting. Seems correct to me.

The font subsystem looked for a 9 pixel font and found an 8 and 10 pixel font.
It choose the 8 pixel font (nearest size, if tied then lower). Seems correct 
to me.

Jeremy: does anything here seem wrong to you?

Are you sure your resolution is 75 DPI (not 96)?


    
    

    
  
My screen is 80.2x74.9 dpi. XFree86 is set to 75x75 and no one seems to know how
to change that, but it's fairly close anyhow.

> Jeremy: does anything here seem wrong to you?

What was the change after 0.9.4 that changed the way that page and others
display? Was the smallest font size Mozilla would honor lowered/removed? Can I
still set it with a hidden pref? That page and others that use 9pt fonts are
pretty much unreadable, and before they were fine.

    
    

    
  
The change after 0.9.4 was probably my checkin to nsDeviceContextGTK.cpp:

revision 1.80
date: 2001/09/05 03:15:55;  author: dbaron%fas.harvard.edu;  state: Exp;  lines:
+4 -2
Make the "browser.display.screen_resolution" pref work again.  b=69205  r=bryner
 sr=waterson


What I'd like to do in the near future is make the pref work consistently across
platforms and then get the default value of the pref as part of the UI (yep,
it's not in the UI -- the default is max(96dpi,System Setting).  The max is that
way for a reason - many web pages were designed by ignorant web designers on
Windows systems with 96dpi logical resolution who assumed 7pt (for some faces)
and 8pt fonts were legible (which they aren't even for normal users at a logical
resolution of 75dpi, and certainly aren't for users with poor vision).

    
    

    
  
*** Bug 104747 has been marked as a duplicate of this bug. ***

    
    

    
  
try adding this to unix.js:

  pref("font.min-size.variable.x-western", 16);
  pref("font.min-size.fixed.x-western", 16);

    
    

    
  
Adding those lines did make the affected web page have bigger fonts, but it also
made the fonts in the user interface bigger than normal and pixilated.

    
    

    
  
No point sticking to these old prefs. Try this one instead (from bug 30910):
pref("font.minimum-size.x-western", 16); // or 10

This one is known to not suffer the problems that you mentioned above.
bstell, sounds like it is time to get rid of the old prefs and swicth to this pref
as it has no pending issues now.
URL: https://system.oraclesmallbusiness.co...
QA Contact: ian
Summary: Change after 0.9.4 made 9pt and under fonts too small

    
    

    
  
Don't use that build.
Restoring sum/qa/url
URL: https://system.oraclesmallbusiness.co...
QA Contact: ian
Summary: Change after 0.9.4 made 9pt and under fonts too small

    
    

    
  
min-size is still in use.

    
    

    
  
I added pref("font.minimum-size.x-western", 16); to my unix.js and it took care
of the font being too small and isn't changing the font in the, but now the font
inside <PRE> tags has gotten much larger and in some cases is causing the text
to not fit in a viewing window horizontally.



    
    

    
  
16 is way too large for normal browsing - 9 or 10 might be better if you want to
keep the pref on for good.

    
    

    
  
10 doesn't solve the problem of the font being too small.  12 seemed to run all
the letters together, as if the space between them wasn't being included.  At 14
the text seemed a little distoreted, but the size was big enough, but at that
point the text in <PRE> tags is already too big.  Is there a way for the
monospaced fonts to be treated seperatly?

    
    

    
  
> Is there a way for the monospaced fonts to be treated seperatly?
No. It was decided in bug 61883 not to do so (but compelling reasons can lead to
a revision of the decision).

Seems that you need other fonts or a proper fix for this bug (since the
minimum-size itself is still under the effect of your original DPI problem).
Feel free to file a bug against dbaron (see comments of "2001-10-22 22:33") to
get the ball rolling for what he mentioned above.

    
    

    
  
I'm not familiar with the Mozilla codebase so I'm not really sure what the code
is that causes this problem.  Why do we need another bug besides this one?

I still don't understand why this one was marked invalid.  Are you saying that
the fonts are being displayed as the size they are asked to be, but we have
wrong expectations for what that should be?  Or is it that Mozilla is getting
the wrong dpi from the system and thus displaying the fonts too small?  ('You'
here is collective)

    
    

    
  
A combination of that.
-> Re-opening
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

    
    

    
  
*** Bug 108378 has been marked as a duplicate of this bug. ***

    
    

    
  
I recently reported a dup bug on this, as mentioned in the above comment.  I'm
seeing this problem really dink up my web site at http://www.testequity.com/ for
nearly all my fonts.  I'm running Mozilla on a FreeBSD laptop for testing.

On 0.9.4 this site renders exactly as I would expect it too.  Anything later
than that, to include an 11/7 build, goofs things up.  I tried working some of
the suggested prefs tweaks mentioned here, but they aren't really helping. 
While they do make the fonts bigger, the relative sizes to eachother are wrong.

For a reference, Communicator 4.78 still renders this page properly on FreeBSD,
if you no longer have an older version of Moz installed.  In particular, note
the fonts along the left hand menu and the ad copy in the middle of the page. 
The default font size I have in the style sheet is 10pt, and the menu on the
left is set to an 8pt.  It almost starts looking right when you zoom the text to
120%.

I'll be the first to admit I'm not a style sheet expert, and I may have an error
in what I've done.  Thing is, the latest builds of Mozilla are the only ones
presently having problems with my styles.  rbs was kind enough to do up a
viewable link to this style sheet for review.

http://webtools.mozilla.org/web-sniffer/view.cgi?url=http://www.testequity.com/Styles/TQSite.css

I'd be more than happy to modify this style sheet off-line with any
recommendations that come across this bug to see if it can be narrowed down a
bit.  Additionally, I can do up some screen shots if requested.


    
    

    
  
> I tried working some of the suggested prefs tweaks mentioned here, but they
> aren't really helping. While they do make the fonts bigger, the relative sizes
> to eachother are wrong.

The DPI problem really needs its fix since the minimum font-size stuff is not
meant to be a substitute for that problem.

    
    

    
  
i'm seeing the same on:
https://bankieren.rabobank.nl/rib/qsla.htm?Abs-Pad=rib/rib.cgi&Niv=3&Aanmeld-rdn=971&X009=&X010=0020&X015=REKSAL
(a banking site)

the text is unreadable small (OK with IE, NS 4.77)
changing font prefs has no effect.

PC linux (RH 7.1)
0.9.5

    
    

    
  
*** Bug 104850 has been marked as a duplicate of this bug. ***

    
    

    
  
Some DPI pointers: bug 83060, bug 83061

    
    

    
  
Watch out if the fix for bug 104576 also fixes this. There was apparently a
problem in nsDeviceContext[GTK | Xlib]::SetDPI(PRInt32 aDpi).

    
    

    
  
The fix for bug 104576 was checked in last night. I downloaded this morning's
build and the problem still exists. Did the fix actually make it into this
morning's build?

    
    

    
  
*** Bug 107260 has been marked as a duplicate of this bug. ***

    
    

    
  
I don't know if this helps or not, but hitting ctrl + on sites where the fonts
are too small seems to bring them up to the proper (0.9.4) size. Of course, then
all the sites that don't share this problem display far too big.

Ars Technica http://www.ars-technica.com does a great job of demonstrating this
problem. The links on the nav bar on the left side of the page display the same
in 0.9.4 and 0.9.5+ because their size is defined in pixels. The text of the
news items and the headlines appear smaller in 0.9.5+ than they do in 0.9.4
because their size is defined in points. This is true even though they are
defined > 9pt (thus this bug seems to affect more than the summary would indicate).

Is Mozilla just having some problems with figuring out the proper point sizes
with arial / Verdana / helvetica style fonts?

    
    

    
  


  
This code selects the nearest size between two fonts. The rule has been to
pick the smaller size when they are equal distant from the correct size.
Because in the past the line height was not measured but assumed that the
font would be the correct size an oversized glyph could lead to text
overlapping with the text in the line above or below. Since we now measure
the text the overlap problem has been solved (bug 99010) and either size
would be okay.

This patch continues the previous behavior as before (minimal disturbance)
with the one change that when the smaller size is small (<9 pixel) chose
the larger size.

    
    

    
  
this issue people are seeing has several parts:

 1) Older moz code got the desired size wrong and this has been fixed
    leading to requests for font size 9 pixel; ie: an old bug that made
    moz look good has been fixed.

 2) When picking font we always leaned toward the smaller font to
    avoid text overlap. This problem has been fixed hence the choice of
    a smaller font is not always a better choice.

The patch is something of a (minor) hack but since many people find they have
8 pixel and 10 pixel verdana fonts and a 10 pixel far more readable (since
it is about 50% bigger) than an 8 pixel the patch avoids the tiny font.

I'm not especially excited about this patch but it is a minor change and people
have been complaining for some time.


    
    

    
  
Would eaither a much better selection of bitmaped fonts, or a
truetype/opentype/type1 font in the correct face solve the issue as well?

It's good to fallback as gracefully as possible, but perhaps Linux distributions
should be made aware from the mozilla project what fonts are sorely needed. No
other apps really need a specific font face and size, except web browsers, where
you need to match fonts with what the designer had in mind (yelch).

Mozilla's font rendering is already 1000 times better then NS4.x's on Linux, but
if fonts are the bottleneck now, maybe blizzard and others can get something
done in that area.

    
    

    
  
> Would eaither a much better selection of bitmaped fonts, or a
> truetype/opentype/type1 font in the correct face solve the issue as well?

Yes, better fonts would help.

At small sizes outline scaled with/without anti-aliasing produce
mediocre results. Hand tuned fonts look the best.

Right now blizzard is suggesting we wait until Xft is usable and as such
has been vetoing my attempts to add FreeType2 without Xft.

Sadly, by the time Xft is ready I will be long gone and no one will be around
that understands how the font system works. Something will get put in by 
someone that does not understand how the font system work. I feel very sorry 
for the i18n engineer that gets stuck with trying to keep it working. But,
hey, it won't be my problem.


    
    

    
  
> by the time Xft is ready I will be long gone and no one will be around
> that understands how the font system works

Start documenting now :)

> But, hey, it won't be my problem.

It's open source... it can be. :)

    
    

    
  
I'm a little confused by some of the comments on this bug.  I'm seeing this 
problem on a site asking for 8pt Arial font, and I have the actual Microsoft 
fonts installed on this FreeBSD machine.  0.9.4 renders fonts perfectly in 
line with what a user sees on a Windows box.  Something changed in the Mozilla 
code, not in the fonts.

Why can't the dpi code go back to the way things were at 0.9.4 until other 
factors not allowing Mozilla to work properly get corrected?  I guess I'm just 
not seeing the up side to the changes that were made, only an unusable browser 
here.


    
    

    
  
> Why can't the dpi code go back to the way things were at 0.9.4 until other 
> factors not allowing Mozilla to work properly get corrected? 

It seems like a bad idea to reintroduce a bug into the font code to cover
up a bug in some other part of the code.

    
    

    
  
> It seems like a bad idea to reintroduce a bug into the font code to cover
> up a bug in some other part of the code.

Since when?  If a bug fix causes additional problems down the line because 
other components weren't yet ready, you pull the first bug fix.  Especially 
true of the new bug created is worse than the first.  Prior to the last "fix" 
to the font code Mozilla appeared to be flawless in it's rendering for any of 
the pages I wrote or browsed to.  As of 2 milestones later Mozilla still can't 
get a plain Arial font right when called from a stylesheet.  This has kept me 
at 0.9.4 due to the problem, because everything after that provides me totally 
unreliable, and unreadable text.

Aside from the principle of the matter, why can't the new font code introduced 
post 0.9.4 be reverted back and have it set aside until the xft or freetype 
issues are sorted out?


    
    

    
  
Why would an engineer want spend time to make the font code function 
incorrectly?

You need to be pushing to get the other code fixed.


    
    

    
  
Could the people who are seeing this problem see if they have the
"browser.display.screen_resolution" pref set to a non-default value?  If so,
could you try removing the line from your prefs.js (in
~/.mozilla/<Profile-Name>/<random letters>/prefs.js" to see if it fixes the
problem?  See comment 35.

    
    

    
  
I see the problem and I have no browser.display.screen_resolution
 setting in prefs.js at all. I'm using the 2001121006 build.

    
    

    
  
Using build 2001122207 here now, and it looks like this problem is now gone. 
Well, gone if you go into the prefererences and change the font resolution
setting to 96dpi.  Mind you, this setting only really takes effect after a
restart of Mozilla.  This had me puzzled for a bit as the browser screen "looks"
like it's refreshing with the new dpi setting.

I'd hesitate to actually call this bug fixed as I'm pretty sure this laptop I'm
running on here isn't set to 96dpi.  Certainly its importance in getting fully
resolved has dropped quite a bit in my mind.


    
    

    
  
I just tried the same thing that #69 suggested. I didn't need a restart. Once I
switched to 96 dpi, all the sites that I have problems with started displaying
correctly again. This is with 0.9.7. FWIW, xdpyinfo reports that my screen
resolution is set to 81x81. Was there some DPI checkin recently?

    
    

    
  
My real screen DPI is 92 and I have set that in mozilla too, but I still need to
use user_pref("font.minimum-size.x-western", 13); to get decent size in
tinderbox sidebar and on some sites.

    
    

    
  
Andre, have you tried moving the setting to 96dpi just to see?  Also, which 
sites are you still having problems with?  Be curious to see if the rest of us 
still see those same problems.


    
    

    
  
Michael, no it didn't make a difference. Even if it did it would have been wrong
since my Xservers setting is 92 dpi. I will attach two screnshots comparing how
the sidebar looks with and without the minimum-font pref.

    
    

    
  
We have clearly seen that some users would prefer that the glyphs
not be below a minimum size. We should address this.

Why are the glyphs so small?

What should we do to help the user?

I believe that this is the URL the screens shots came from:
http://tinderbox.mozilla.org/SeaMonkey-Ports/panel.html

Here is part of the source for this: 

 <style>
   body, td { 
          font-family: Verdana, Sans-Serif;
          font-size: 8pt;
        }

The glyphs in the 1st attachment 62662 [details] are at least 10 pixels tall.

If the screen resolution is 81 DPI then wouldn't 

  8 point => 8 * 81/72.5 = 9 pixel?

Assuming I am calculating this correctly, doesn't this mean that the glyphs 
in the 1st attachment are already *bigger* that the HTML/CSS specifies?

If so, then perhaps we should consider a UI to let the user easily
specify minimum font size.

Perhaps the issue is that web content that is tuned for a 96DPI display
is too tight for a 75-81 DPI display.

Perhaps the issue is that the web content designer's system is mis-configured
and what looks good on the designer's system looks bad on a correctly
configured system.


    
    

    
  
Andre, assuming that the shot in question is specifying an 8pt font, that
graphic you attached has exactly what I would expect out of an 8pt font. 
Originally this bug was due to fonts being so small that the letters literally
fell in on each other and were totally unreadable.

Unless there's something I'm missing, it seems that you're asking for more of a
feature, or usability, request in dealing with small fonts like Konqueror has. 
The real question is whether or not the fonts look different when viewed on a
Windows box with IE or Netscape 4.7x, or if the fonts are legibly displayed.

    
    

    
  
It seems like many of the comments indicate that this bug no longer exists. 
Because of that, and since this bug is way too confusing anyway (it doesn't
describe a single bug, certainly), marking as WORKSFORME.  Bugs that still exist
should be filed as separate bug reports.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
May I recommend: since users will continue to "confuse the issue"(1) 
we have a bug open that this one references. Lacking this we should
expect this bug to continue being reopened.

1:
Users assume that when they see the new/smaller fonts that the new size
is a bug since they (justifiably) don't like the new size. The confusion is 
that the older/bigger fonts were actually wrong and the newer/smaller fonts
are (nearer) the document specified size.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: