Open Bug 928449 Opened 11 years ago Updated 2 years ago

Text rendering (position, size) fails when text (system fonts or web fonts) is enlarged by either increasing Font Size or Scale Transform beyond a threshold

Categories

(Core :: Graphics: Text, defect)

Product:
Core
Component:
Graphics: Text
Platform:
x86_64
Linux
Type:
defect

Tracking

()

People

(Reporter: ideami, Unassigned)

References

(
URL
)

Details

(Keywords: platform-parity, testcase, Whiteboard: [x11])

Attachments

(13 files)

Comparison between correct render on windows firefox on left, and broken render on linux firefox on right
439.87 KB, image/jpeg
Details
browsershots.org results showing linux firefox bug, Linux-Chrome look matches browsers in all other platforms, only Linux Firefox breaks when scale goes above a number
152.75 KB, image/jpeg
Details
More detailed captures and comparisons between platforms and browsers to highlight linux+firefox bug
861.87 KB, image/jpeg
Details
linux-firefox-bug-with-font-size-only-oct25-2013.jpg
516.63 KB, image/jpeg
Details
simplified testcase
869 bytes, text/html
Details
browsershots-captures-comparison1.jpg
861.87 KB, image/jpeg
Details
browsershots-captures-comparison2.jpg
861.87 KB, image/jpeg
Details
linux-firefox-bug-with-font-size-only-oct25-2013.jpg
516.63 KB, image/jpeg
Details
windows-firefox-5000-pixels-captured-at-amazon-ec2-microinstance.png
462.09 KB, image/png
Details
windows-9000-pixels-firefox-amazon-ec2-microinstance.png
1.09 MB, image/png
Details
windows-5000-pixels-single-letter-firefox-amazon-ec2-microinstance.png
218.13 KB, image/png
Details
windows-7000-pixels-single-letter-firefox-amazon-ec2-microinstance.png
404.86 KB, image/png
Details
windows-7000-single-perfect-positions-firefox-amazon-ec2-microinstance.png
473.71 KB, image/png
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Steps to reproduce:

This problem seems to happen in the Linux version of Firefox. It does not seem to happen in the Windows version.

1) Create a DIV and a few text elements using Web Fonts with absolute positioning and css3 scale transforms applied

2) Increase the scale transforms either of the individual elements or better of the entire containing frame.  




Actual results:

3) When reaching a threshold, positions and sizes of the texts (images are not affected) begin to fail and the more you continue increasing the scale the more they diverge from their expected numbers

The issue is very easy to reproduce and happens always but i haven't been able yet to understand what is the exact threshold that triggers it. All i know is that this doesn't seem to be an accumulation issue, it does not happen gradually. When scale transform is below X number it doesn't happen at all and then suddenly starts happening when scale transform goes above X number. However, once it starts happening then yes it gradually degrades as scale keeps going up.

Important note: The problem only affects Text divs, web font text divs, not images. If i have a background image , images are not affected at all. Only font text divs are affected by this problem

This problem seems to happen specially or only in the Linux version of Firefox. It does not seem to happen in the Windows version.



Expected results:

What should have happened is that as you keep on increase the CSS3 scale transform of the entire container, the positions and sizes of the individual text divs inside remain consistent and in proportion as before.
I have now used remote browser testing services  http://browsershots.org and https://saucelabs.com
to confirm that this looks like a bug 

basically, after passing a certain css3 scale transform, the position and sizes of texts match in 
Linux Chrome, Windows Chrome and Windows Firefox, etc exactly with total precision

but break in Linux Firefox which is the only one to differ.
I have the browsershots image results that show very well the bug, not sure how to attach it here though
browsershots.org results showing linux firefox bug, Linux-Chrome look matches browsers in all other platforms, only Linux Firefox  breaks when scale goes above a number
Just attached browsershots.org captures showing the bug,
i captured this page  :  http://volandino.com/subscriptions/demobug2.php
that takes some text divs passed that scale transform number,
this confirms its a bug related to Linux Firefox (doesnt happen on windows, etc)
OS: Windows 7 → Linux
URL: http://volandino.com/subscriptions/de...
Keywords: css3
Reproduce easily this bug in Linux Firefox with these 2 URLs

1) Bug not happening when scale transform doesn't reach the threshold
http://volandino.com/subscriptions/demobug.php

2) Bug happening after scale transform reaches the threshold
http://volandino.com/subscriptions/demobug2.php

thank you

(Bug is now confirmed to happen on Linux Firefox, i have tested with Browsershots.org and saucelabs.com and bug does not happen in windows, Mac, etc; It happens specifically on Linux Firefox)
Reproduce easily this bug in Linux Firefox with these 2 URLs

1) Bug not happening when scale transform doesn't reach the threshold
http://volandino.com/subscriptions/demobug.php

2) Bug happening after scale transform reaches the threshold
http://volandino.com/subscriptions/demobug2.php

thank you

(Bug is now confirmed to happen on Linux Firefox, i have tested with Browsershots.org and saucelabs.com and bug does not happen in windows, Mac, etc; It happens specifically on Linux Firefox)


(In reply to javismiles from comment #0)
> Created attachment 819090 [details]
> Comparison between correct render on windows firefox on left, and broken
> render on linux firefox on right
> 
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/30.0.1599.101 Safari/537.36
> 
> Steps to reproduce:
> 
> This problem seems to happen in the Linux version of Firefox. It does not
> seem to happen in the Windows version.
> 
> 1) Create a DIV and a few text elements using Web Fonts with absolute
> positioning and css3 scale transforms applied
> 
> 2) Increase the scale transforms either of the individual elements or better
> of the entire containing frame.  
> 
> 
> 
> 
> Actual results:
> 
> 3) When reaching a threshold, positions and sizes of the texts (images are
> not affected) begin to fail and the more you continue increasing the scale
> the more they diverge from their expected numbers
> 
> The issue is very easy to reproduce and happens always but i haven't been
> able yet to understand what is the exact threshold that triggers it. All i
> know is that this doesn't seem to be an accumulation issue, it does not
> happen gradually. When scale transform is below X number it doesn't happen
> at all and then suddenly starts happening when scale transform goes above X
> number. However, once it starts happening then yes it gradually degrades as
> scale keeps going up.
> 
> Important note: The problem only affects Text divs, web font text divs, not
> images. If i have a background image , images are not affected at all. Only
> font text divs are affected by this problem
> 
> This problem seems to happen specially or only in the Linux version of
> Firefox. It does not seem to happen in the Windows version.
> 
> 
> 
> Expected results:
> 
> What should have happened is that as you keep on increase the CSS3 scale
> transform of the entire container, the positions and sizes of the individual
> text divs inside remain consistent and in proportion as before.
Hi javi, can you create and either attach or link to an html file that demonstrates the bug? That will help us to replicate it. Thanks!
Flags: needinfo?(ideami)
Oh, wait, I just saw your links in Comment 5. Sorry about that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(ideami)
yes thank you Liz, apologies i should have put the links from the beginning :) I'm here to help in anything else you need :)
when running the two URLs, just check the distance between left yellow android shape and big letter S to its right.
Results are correct on Firefox on windows, Mac , etc as well as on Chrome, Safari on all platforms, results match exactly in all of those, and only fail on Linux-Firefox where after reaching a certain transform scale number, you will see how the android shape and text letters just change size and position in strange ways and separate from each other and become smaller (which causes trouble in our app which needs to scale a lot items and capture them later)

1) Bug not happening when scale transform doesn't reach the threshold
http://volandino.com/subscriptions/demobug.php

2) Bug happening after scale transform reaches the threshold
http://volandino.com/subscriptions/demobug2.php
More detailed captures and comparisons between platforms and browsers to highlight the linux+firefox bug
today i did further tests and i found something incredible, that the bug i found affects all types of fonts (also system fonts, not just web fonts) and even if you use simply Font-size without having to do a transform-scale at all.

The demonstration is in this demo page:
http://volandino.com/subscriptions/demobug7.php
and image attached with browser shots captures also)

Basically in that demo page, i am using system fonts (Arial), no web fonts, and im keeping scale to 1, no increase of transform scale, and all im doing is increasing the old friend Font-Size in css. Once font-size reaches a threshold, texts break like crazy.

Again only in Firefox+linux,  other platforms are ok

browsershots captures here also:
http://volandino.com/subscriptions/linux-firefox-bug-with-font-size-only-oct25-2013.jpg

demo page here
http://volandino.com/subscriptions/demobug7.php
today i did further tests and i found something incredible, that the bug i found affects all types of fonts (also system fonts, not just web fonts) and even if you use simply Font-size without having to do a transform-scale at all.

The demonstration is in this demo page:
http://volandino.com/subscriptions/demobug7.php
(and image attached with browser shots captures also)

Basically in that demo page, i am using system fonts (Arial), no web fonts, and im keeping scale to 1, no increase of transform scale, and all im doing is increasing the old friend Font-Size in css. Once font-size reaches a threshold, texts break like crazy.

Again only in Firefox+linux,  other platforms are ok

browsershots captures here also:
http://volandino.com/subscriptions/linux-firefox-bug-with-font-size-only-oct25-2013.jpg

demo page here
http://volandino.com/subscriptions/demobug7.php
Summary: Text rendering (position, size) issues when css3 scale transforms are large beyond a threshold → Text rendering (position, size) fails when text (system fonts or web fonts) is enlarged by either increasing Font Size or Scale Transform beyond a threshold
Component: Layout → CSS Parsing and Computation
All the "demo page" urls above seem to be 404.  Can you please attach your testcases directly to this bug?
Flags: needinfo?(ideami)
Jonathan, any idea what's going on here?
Flags: needinfo?(jfkthame)
Hi Jonathan, all the links are now working with images and demos of the bug, if you need any other info, explanation, case scenario, description, image, etc i'm here to help with anything you need, thanks lots, Jav

http://volandino.com/subscriptions/demobug7.php
http://volandino.com/subscriptions/linux-firefox-bug-with-font-size-only-oct25-2013.jpg
http://volandino.com/subscriptions/demobug2.php

https://bug928449.bugzilla.mozilla.org/attachment.cgi?id=819385
https://bug928449.bugzilla.mozilla.org/attachment.cgi?id=822174
(In reply to Boris Zbarsky [:bz] from comment #15)
> Jonathan, any idea what's going on here?

At a guess, perhaps text positioning that's based on pixel-snapped metrics for one size, then being scaled to a vastly different size.

(In reply to javismiles from comment #16)
> Hi Jonathan, all the links are now working with images and demos of the bug,
> if you need any other info, explanation, case scenario, description, image,
> etc i'm here to help with anything you need, thanks lots, Jav

It would be really helpful to have a -minimal- testcase that demonstrates the issue; not much more than a <span> or two and a couple of lines of CSS, ideally. Thanks!
Flags: needinfo?(jfkthame)
Hi Jonathan, good day, I am right now creating a new version of the demo of the bug that is much more simple , super simplified and showing the bug super clearly, will post here in a little bit, best
hi friends, its ready, i have super simplified the demonstration of the bugs, now they are super simple and much much easier to see, im actually excited that i can demonstrate you super clear now the bug

The bug happens when making text large with either Font-Size or Scale Transform so i have two demos for you showing you the bug with both ways

1) Font-Size Bug
http://volandino.com/subscriptions/bug-fontsize.php

You have to look at the two big LETTERs A. you will see that when bug does not happen the Green Letter A and the Red Letter A are touching each other.

a) Run the link in Windows Firefox or Mac Firefox, or in Chrome in any platform or any other browser, etc you will verify that Green and Red letters A touch each other: http://volandino.com/subscriptions/bug-fontsize.php

b) Now Run the link in Linux Firefox. As you can see everything goes wrong, both positions and sizes of texts go completely wrong


2) Scale Transform Bug
http://volandino.com/subscriptions/bug-transform-scale.php

a) Run the link in Windows Firefox or Mac Firefox, and in Chrome in any platform, or Explorer etc you will see the two big letters R on the very left of frame and the round part of the big A on the right. http://volandino.com/subscriptions/bug-transform-scale.php

b) Now Run the link in Linux Firefox. As you can see everything goes wrong, both positions and sizes of texts go completely wrong.

a) Those are the two examples .Its very important to see that not only position goes wrong, sizes also. When a certain threshold is passed, Both Position + Size go wrong, not just position, sizes of texts also.

b) In the demos i provide two buttons (below the frame) to perform immediate captures in chrome+linux and firefox+linux through phantomJS and SlimerJS to very quickly see the results. Also browsershots.org can be used to demonstrate that bug only happens in Linux+Firefox,  it does not happen in Windows+Firefox or Mac+Firefox, or Chrome, Explorer, etc

Code is extremely minimal, ignoring the extra bits i added for the captures, this is the code of each demo:

Bug 1: (Font Size)

   <div class="scaleframe">
    <div id="mytext3" class="textparameters3" >Large</div>
    <div id="mytext4" class="textparameters4">Large</div>
   </div>

.textparameters4 {position:absolute; left:-660px; top:325px; font-family:Arial; font-size:1333px; color:green; }
.textparameters3 {position:absolute; left:-45px; top:330px; font-family:arial; font-size:1300px; color:red; }
.scaleframe {position:absolute;left:0px;top:0px; width:1280px;height:720px;background-color:#eeeeee;overflow:hidden;}

_____________

Bug 2: (Scale Transform)

   <div class="scaleframe">
    <div id="mytext3" class="textparameters3" >Large</div>
    <div id="mytext4" class="textparameters4">Large</div>
   </div>

.textparameters4 {position:absolute; left:160px; top:325px; font-family:Arial; font-size:48px; color:green;
transform: scale(50,50);-webkit-transform:scale(50,50); -ms-transform:scale(50,50);} 
.textparameters3 {position:absolute; left:115px; top:330px; font-family:arial; font-size:48px; color:red;
transform: scale(50,50);-webkit-transform:scale(50,50); -ms-transform:scale(50,50);}
.scaleframe {position:absolute;left:0px;top:0px; width:1280px;height:720px;background-color:#eeeeee;overflow:hidden;}


thank you for your support, hopefully we can fix this, thank you again
its key the point that not only positions go wrong but also sizes, both position+size of texts go wrong in linux-firefox whereas in any other browser including firefox in windows and mac, both position+size are the correct ones

Font-Size: http://volandino.com/subscriptions/bug-fontsize.php
Scale-Transform: http://volandino.com/subscriptions/bug-transform-scale.php

Bug 1: (Font Size)

   <div class="scaleframe">
    <div id="mytext3" class="textparameters3" >Large</div>
    <div id="mytext4" class="textparameters4">Large</div>
   </div>

.textparameters4 {position:absolute; left:-660px; top:325px; font-family:Arial; font-size:1333px; color:green; }
.textparameters3 {position:absolute; left:-45px; top:330px; font-family:arial; font-size:1300px; color:red; }
.scaleframe {position:absolute;left:0px;top:0px; width:1280px;height:720px;background-color:#eeeeee;overflow:hidden;}

_____________

Bug 2: (Scale Transform)

   <div class="scaleframe">
    <div id="mytext3" class="textparameters3" >Large</div>
    <div id="mytext4" class="textparameters4">Large</div>
   </div>

.textparameters4 {position:absolute; left:160px; top:325px; font-family:Arial; font-size:48px; color:green;
transform: scale(50,50);-webkit-transform:scale(50,50); -ms-transform:scale(50,50);} 
.textparameters3 {position:absolute; left:115px; top:330px; font-family:arial; font-size:48px; color:red;
transform: scale(50,50);-webkit-transform:scale(50,50); -ms-transform:scale(50,50);}
.scaleframe {position:absolute;left:0px;top:0px; width:1280px;height:720px;background-color:#eeeeee;overflow:hidden;}
Attached file simplified testcase — 
It looks like we're limiting the font size used to about 1000px, as demonstrated by this example. Here, the red text should remain consistently 10% larger than the green as the two words are animated; but its size appears to be "clamped" at 1000px, so that as the animation reaches its maximum size, the red stops growing and the green catches up with it.

If you zoom out by a couple of steps, so that the font size stays below 1000px even at its largest, the problem no longer occurs; conversely, if you zoom in, it kicks in earlier during the animation.
Attachment #829745 - Attachment mime type: text/plain → text/html
Note that with this example, I see the same problem on OS X, too.
Jonathan thank you very much for the added example and the insights,
yes that makes sense, it seems that there is a threshold somewhere that limits the scaling up,

our app's key feature needs to capture snapshots of zoomed parts of designs so this problem totally blocks our key feature unfortunately,

it is possible as you say that when size goes too extreme the problem may happen in some other platform also, but in general this problem doesnt happen in the vast majority of other browsers/platforms as shown in the tests i did with browsershots.org (i attach the past captures of those tests i did)

i havent seen the problem either with chrome or explorer, i think i did see it once with opera if i remember well, again if going too extreme

i feel that given that through browsershots.org i have seen that the bug happens since many many past versions and that things have changed so much in the last years in terms of screen resolution, maybe this is a threshold limitation that comes from the old times when resolutions and sizes were so much smaller. When screen resolutions were 800 pixels wide and css capabilities were more limited many years ago this threshold probably didn't cause any probs, but today it is normal to have web apps managing canvases and divs of thousands of pixels of size and elements within the dom scaled with css to very large sizes via scale transform or other means so this threshold limitation i feel wouldn't make sense (which is why problem doesn't happen to me in chrome, explorer etc)

by the way even though we can see that the problem happens when changing size via either font-size or scale-transform, in our app we only really trigger it mainly through scale-transform as we are scaling things via scale-transform, leaving font-size small, in any case the problem happens either way so i guess it's all the same problem

hopefully we can change that threshold :) thank you very much for looking into this :)
these is example of browsershots.org captures showing that the vast majority of browsers/platforms don't have this problem
this is the other example of browsershots.org captures showing that the vast majority of browsers/platforms don't have this problem,

ignore the text below captures as it's from weeks ago and since then more details of problem have been found
sorry added wrong one, this is the other one :)
to me this reminds me of the phrase of bill gates when he said that "640K is more memory than anyone will ever need" :) , probably many years ago (because i see this happening in browsershots.org since many many versions ago), somebody thought we will never need to scale a text beyond X number, but things have changed dramatically in last years and today screens are huge, css is powerful and we are building web apps that scale elements large, zoom, capture, etc and that threshold doesn't make sense anymore,and that's why in my browsershots.org experiments i see the overwhelming majority of browsers and platforms around not having this problem
one interesting thing to check would be this,
we are currently testing our app with a windows server, because we use SlimerJS which uses firefox and firefox in Windows does not have this problem, it works 100% perfect, so for testing its perfect, (of course this is good only for testing as we release apps only on linux servers and we dont want to have a second windows server on the side), so given that Firefox Windows works perfect and doesnt have this problem one interesting thing would be to check with the Windows Firefox team which is the threshold that they have , to compare, as i can guarantee that windows firefox has zero issues with this, we have forced it to the limit and this problem never happens there  (of course it also doesnt happen with Chrome browser for example, but its specially useful that it doesnt happen with Windows firefox as then you could check and compare what thresholds they have i guess)
while is being decided what to do about this issue, it would be awesome if there was a way for us to get a recompiled version of XulRunner for example with this threshold taken out, that way i would be able to verify already if taking that threshold out the problem in our app disappears, that would be awesome :) ; i have no idea if such thing is possible but if it is, if somebody could recompile a XulRunner without that threshold to test it in our app, or tell us on what module-line is the threshold that could be removed and/or if we had instructions on how to recompile a new version removing that threshold, if such thing is possible; of course best for us would be if the threshold is changed in the official version but while we wait for that (if it ends up happening), it would be awesome to be able to test a version without the threshold to verify if it solves our problem :)thank u for any help :)
i see that here are instructions to recompile Xulrunner (Xulrunner is all we would need because we use SlimerJS which uses either XulRunner or Firefox), https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner/Build_Instructions but also we would need a version of the source with that limit-threshold removed; i dont know how complicated this is, but would be awesome to get Xulrunner without the limit as then we can test to see if it solves the problem of our app :)
I've downloaded the source code now through Mercurial, interesting to browse through the cpp files , i was taking a look just now at the HTMLFontElement.cpp (  // size: int nsCSSValue* fontSize = aData->ValueForFontSize();) , hopefully we can find where that limit threshold is, in any case i'm curious about, if there is a single cross-platform source code that then is compiled for each platform (windows, mac, linux) then isnt it kind of odd that Windows Firefox doesnt have this problem and renders text perfectly no matter what size we give it, and linux has this problem so clearly and consistently, and yet  they both use same source code apparently for what I'm reading (if i'm reading correctly :) )
by the way Jonathan your test is really great ("If you zoom out by a couple of steps, so that the font size stays below 1000px even at its largest, the problem no longer occurs; conversely, if you zoom in, it kicks in earlier during the animation.")  , because it demonstrates that its the overall size that matters, regardless of how we get there (via zoom, font-size etc), very cool, hopefully there is a line somewhere to experiment with, similar to the one i just found in the console.js file
webconsole.js : if (fontSize != 0) {fontSize = Math.max(MIN_FONT_SIZE, fontSize);
(of course it would have to be the opposite, with the Max font size instead of min font size), 

or like the one i just found about Cairo:
https://github.com/bitwiseworks/mozilla-os2/blob/master/gfx/cairo/max-font-size.patch
which curious enough happens to be 1000 the threshold of Cairo

+/* This is the maximum font size we allow to be passed to FT_Set_Char_Size
+ */
+#define MAX_FONT_SIZE 1000
 
+        double x_scale = MIN(sf.x_scale, MAX_FONT_SIZE);
+        double y_scale = MIN(sf.y_scale, MAX_FONT_SIZE);


hopefully somewhere in the firefox code there is a similar threshold comparison that can explain this behaviour, and if such thing exists in the worst case we could experiment recompiling without that limit to see if it solves the prob
i just found this in the wiki
"The Mozilla project has made use of cairo in recent versions of its Gecko layout engine, used for rendering the graphical output of Mozilla products. Gecko 1.8, the layout engine for Mozilla Firefox 2.0 and SeaMonkey 1.0, used cairo to render SVG and <canvas> content. Gecko 1.9,[13] the release of Gecko that serves as the basis of Firefox 3, uses cairo as the graphics backend for rendering both web page content and the user interface (or "chrome")."

so now im wondering if the threshold limit is actually indeed this
https://github.com/bitwiseworks/mozilla-os2/blob/master/gfx/cairo/max-font-size.patch

+
+/* This is the maximum font size we allow to be passed to FT_Set_Char_Size
+ */
+#define MAX_FONT_SIZE 1000
 
 /*
  * The simple 2x2 matrix is converted into separate scale and shape
@@ -682,9 +686,11 @@ _cairo_ft_unscaled_font_set_scale (cairo
     FT_Set_Transform(unscaled->face, &mat, NULL);
 
     if ((unscaled->face->face_flags & FT_FACE_FLAG_SCALABLE) != 0) {
+        double x_scale = MIN(sf.x_scale, MAX_FONT_SIZE);
+        double y_scale = MIN(sf.y_scale, MAX_FONT_SIZE);
aha i read that Cairo is not used anymore and now you use another library but maybe the 1000 threshold limit was passed on
I don't know if this is related to the issue but in case it can help in something:
https://github.com/cgjones/mozilla-central/blob/master/gfx/cairo/README
max-font-size.patch: Clamp freetype font size to 1000 to avoid overflow issues

so maybe the difference between platforms is because in linux you clamp font size to 1000 whereas in windows you don't (firefox windows allows me to go to any size with no problems). The thing is that the fantastic performance i get in windows firefox or in linux+win+mac chrome and others demonstrates that clamping at 1000 is definitely excessive, maybe it made sense years ago but not today. I mean today i can load images of 10000 pixels in browsers and i'm not allowed to display a vectorial scalable font of 1000? when desktop screen resolutions are going up the roof (with resolutions of 2560x1440 already coming out), it doesn't make much sense to me :) hopefully we can tweak the limit or in the worse case you can help me to compile a new version without the limit or something similar , thank you again :)
See also MAX_FONT_SIZE, defined and used in gfxFont.h. This comes from changeset b0c32fe9eb98, in bug 383473. This presumably explains why I am seeing the size limit at 1000px on OS X; I'm running on a Retina display, where 1000px equals 2000 device pixels. On Windows at 96dpi, or on non-Retina OS X, you'll probably see the size being clamped at 2000px instead.

Apparently it was possible for huge font sizes to crash the X Server. I don't know whether this is still an issue, or if we could safely increase the limit for current versions of X, Cairo, etc.

cc'ing Mats and Vlad for any insights.
Jonathan, this is great info and i'm so glad that we are getting to the core of the issue here, thank you also for connecting to Mats and vlad to see what they think; i add a few extra data and thoughts here

- We are currently testing on a Free Amazon EC2 windows Micro Instance, the lowest of the lowest specs (we cannot launch our app in windows but for now we are using it for testing because in windows we don't find this problem), and there we are using slimerJS + Firefox and XulRunner to do captures, so basically windows+firefox, and everything is working perfect no matter what size of fonts we use, we have definitely tried with 2000,3000,4000,5000px, it never breaks :) and we are using the most very basic microinstance in amazon, you know the power of amazon free microinstances, basically lowest of the lowest cpu and memory :)

- So this is an interesting situations, in linux we would have as you say a 1000px limit clearly, in OSX according to you maybe a 2000px, and in windows however no limit or much higher limit (no limit to our effects because our app just never finds it which is great), so are these differences because each OS uses different graphical libraries? So is Cairo being used only on linux then and not on windows?
One thing also, in my tests with browsershots.org i didn't find the problem in Mac OS X but it could be that the configurations of the computers used in browsershots.org just didn't trigger it. What i can confirm for sure is that windows firefox (or any windows browser) never triggers this problem at least not in any case scenario or font size that we need in our app and not even in a tiny amazon ec2 microinstance

- thank you also in advance Mars and Vlad for any other insights, let's see what you all think about the possibility of this limit being raised in linux (for our purpose personally we only need linux, as our App will run always on linux servers so it's only linux that we care about).

- If in the worst case the limit could not be raised in linux, the other thing i would love to know is if somebody could help us maybe then to recompile a separate version without the limit just for us to run on our linux server, at least with that we could keep on going and launching our app and survive for the next year until eventually hopefully this limit is definitely raised :) of course ideally i wish we could raise the limit now as i keep on thinking that 1000 pixels is such a low limit for today's screens and resolutions and i'm definitely puzzled that on windows there doesn't seem to be any limit or issue, not even on an amazon microinstance.

another thing i wonder about, on google chrome i haven't seen in my browsershots.org tests this issue ever happening, not in linux, not in OSx, not in windows, is that because chrome is not using cairo and is using some other library?  

thank you very very much to everybody for your time and support on this, i'm glad we are discussing the issue and getting to its core
have great day

Jav
:)
Jonathan as you said i found on the gfxFont.h
#define FONT_MAX_SIZE 2000.0
and now i also found on file cairo-ft-font.c : 
#define MAX_FONT_SIZE 1000

very interesting, so we would have 1000 for limit in cairo and 2000 in gfx, is cairo used only in linux and gfx in OSX?

then does windows use a totally different graphics library? because as i said we don't find any limit in windows, our windows firefox/xulrunner has used fonts of much higher thousands of pixels with no probs

all very interesting
jav
The FONT_MAX_SIZE limit of 2000 (device pix) is used in gfxFontStyle::GetAdjustedSize(), which should apply to all platforms; however, from a brief look at the code, I think it probably isn't called at all unless font-size-adjust is non-zero.

The limit in cairo-ft-font.c would only apply to platforms where we use FreeType, i.e. Linux, Android, B2G, but not Windows or OS X.

So I'm not sure right now why I'm seeing clamping on OS X with the testcase here, which doesn't use font-size-adjust. But in any case, the limit within cairo-ft-font is probably what you're seeing on Linux.
interesting, that's great info, freetype yes makes sense so it really looks like that's the one affecting linux and our app,
, the OSx thing is a bit odd yes because in my browsershots.org experiments, output in Mac looked pretty good,maybe it just happens in certain cases or configurations as you say yes, thank u again for looking into this
i wonder then, does this mean that for example google chrome doesn't use Freetype in linux, or maybe that they also use Freetype but they don't clamp the font size; by the way i also don't see the problem when using Safari on ipad, and i think chrome and safari both use webkit, so i was thinking maybe webkit uses a different graphics library i guess also in linux;  but now i found this in webkit bugs referring to freetype: https://bugs.webkit.org/show_bug.cgi?id=107733
so it sounds like webkit uses also freetype, if that's the case then maybe the difference is that webkit browsers don't clamp the values before calling freetype
if webkit indeed uses freetype and given that we don't see this problem happening with chrome and safari, hopefully that means that its safe to remove the limit or raise it also in linux, lets see
My current X server, X.Org version: 1.14.3, doesn't crash if I remove the limits.
I recently upgraded to Kubuntu 13.10 so that's probably a fairly modern X version.
I guess it would be safe to remove these limits now, but we should probably test
it on LTS versions of popular Linux distros first.  I would expect those to use
older X versions.  Do we have QA or Try resources that could do that?
Severity: normal → minor
Component: CSS Parsing and Computation → Graphics: Text
Keywords: css3 → pp, testcase
Whiteboard: [x11]
javismiles, which Linux / X versions are you using?
Mats, thank you so much for checking this, these are great news that you tested in that system and it worked ok, my Linux version is Centos 6 64bits, thats the one we will use for sure in our official server where we will launch our App, so its a CentOS 6, 64 bits, would be awesome if we could test there, or if anybody could compile a version without a limit for centOS i would test it very quickly here :) thank you again :)
(I should add that I'm on x86-64 Linux now, and that I was on x86-32 back when
I saw the crash in bug 383473 / bug 348462.)
interesting! this fits with what i was thinking that the limit surely made sense in the past world of 32 bits but that today in the age of 64 bits and huge resolutions and screens, 1000 pixels probably doesn't make so much sense anymore :)
(In reply to Jonathan Kew (:jfkthame) from comment #39)

> So I'm not sure right now why I'm seeing clamping on OS X with the testcase
> here, which doesn't use font-size-adjust. But in any case, the limit within
> cairo-ft-font is probably what you're seeing on Linux.

Looking a bit further, I see that FONT_MAX_SIZE is also applied when creating a gfxFontStyle at http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxFont.cpp#5208. This should limit font sizes to 2000 device pixels.

As such, I'm surprised you're NOT seeing the same limit on Windows.
That's interesting Jonathan, i can assure you 100% that the limit does not happen ever for us on windows. We have been testing with our app for months and never we have seen any problem on windows. The ultimate test has been when recently we got one of the Free Amazon EC2 Microinstances (super low cpu and memory) with Windows installed, and we tested again our app there with windows firefox and xulrunner through slimerjs and zero problems, it works perfect, we can zoom and get to font sizes of thousands of pixels, im talking about 3000, 5000 easily, and more, and zero problems, all works perfect. It is when i saw that the app performs perfect on a tiny amazon ec2 windows microinstance running windows firefox/xulrunner that i decided i had to raise this issue because the comparison between what was happening on windows (as well as on other browsers like chrome, safari) and linux was kind of surreal :)
Jonathan, here is the demonstration, i just did a capture through our app that uses Firefox/Xulrunner through slimerjs, with fonts at around 5000 pixels in our Windows Amazon EC2 microinstance, and attached is the image, positions and sizes were captured perfectly, and the width of image is 5200 pixels :) we don't find a single problem in windows not even on this tiny amazon microinstance
Now here is the ultimate demonstration :) I just went to the extreme creating a capture that goes above what our app needs, i went to a width of 9000 pixels :) and result is perfect, perfect sizes, positions and proportions, perfect all around, on a tiny tiny cpu windows amazon microinstance, running firefox/xulrunner, so really zero problems in windows with 5000 pixels, with 9000 pixels, and i sense that if i go to 15000 pixels it will also work (just takes longer and longer to do the capture cause these free microinstances are prtty weak :) :) )
im actually amazed now because for the purposes of our app we are ok with 5000 or 6000, so i had never tried above 5000, and seeing now that 9000px works on this tiny windows microinstance, wow, again it makes it even more obvious that a limit of 1000px nowadays is just, rather tiny :)
sorry i correct myself, 9000 is not the font size, is the width of the capture apologies ;) in any case the font size is well above 1000 ;)
the previous captures were not very useful because i was using words instead of a single letter , sorry about that apologies, this here is a much better demonstration, this is a 5000 pixel width capture of a single letter, letter E, of a webfont, done now on firefox/xulrunner on windows, on the amazon microinstance, capture worked prefect, size, position etc matched the original perfectly, so this is 5000 pixels in width, the font itself a bit less, maybe 4000 and something :)
And here another cool demonstration, this is using a different webfont, the previous capture was using Keania webfont, this one is using Elsie Webfont, this time width of the capture is 7000 pixels, and is a capture of a single letter, letter E of elsie webfont, again on firefox/xulrunner on a windows tiny ec2 amazon microinstance, position, size, proportions etc all worked perfect :)
and another demonstration, this time i added 3 small texts that each touch 3 edges of the letter so that in the capture i could verify even more for sure that positions, sizes and proportions were perfect, and yeah, they are 100% perfect, and this is a 7000 pixel width capture of a single letter E of a webfont, firefox/xulrunner/windows on ec2 microinstance :)
so now im wondering about another thing, in our app we scale texts not by changing font-size, but by doing scale transforms, i have seen this issue being triggered by both changes in font-size and in transform-scale, both of them, i just wonder if the MAX_FONT_SIZE is controlling all kinds of sizing (by font-size or transform scale, etc) or not, as that could explain why i can go to 7000 pixels on windows firefox even if that font-size limit was still there; on the other hand that would mean that maybe on linux there is another limit somewhere else; however most probably your max_font_size limit is limiting i guess the size of a font by whichever means you get there (scale transform, font-size etc )
In any case as you can see in my attached captures of today, i have no limits and no problems in windows firefox and i can render a single letter of a font at 5000 pixels, 7000 pixels with perfect positioning, sizing etc
Great, but that's an in-tree cairo patch.  IIRC, Firefox as shipped by Linux vendors
is using system cairo libs.  If we get that fix upstream though then I don't see any
problem with removing our font size limits.

In any case, we could start by removing gfx/cairo/max-font-size.patch since it seems
obsoleted by the later patches.  (FTR, it was added in bug 322345)
that would be great, can't wait to test our app with a version that has the limits removed :)
while we wait for this discussion to proceed, we would really like to test a centos 6 64bit xulrunner without the limits in order to confirm if it solves the problem in our app, so just wanted to ask for advice here, if we download the sources from mercurial (which we already did), and we comment out these lines
cairo-ft-font.c : 
#define MAX_FONT_SIZE 1000
gfxFont.h
#define FONT_MAX_SIZE 2000.0

and then try to rebuild xulrunner according to
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner/Build_Instructions

will that be enough to test a new version without the limits? or are there other lines/areas that would need to be modified?

thanks a lot for any tip/advice :)
sorry i didn't mean to write "comment out" , i should have written "change the numbers to higher values" :)
I have good news, i'm glad to inform that i managed to make a new build with the latest Xulrunner on my centos 6 64 bits, modifying the values in these 2 files
cairo-ft-font.c : 
#define MAX_FONT_SIZE 1000
gfxFont.h
#define FONT_MAX_SIZE 2000.0

and using a mozconfig with

ac_add_options --enable-application=xulrunner
ac_add_options --disable-system-cairo
mk_add_options MOZ_OBJDIR=@topsrcdir@/obj-xulrunnerfinished

and it works!!!!!! The Font Size Issue goes away!
So now we confirm that those lines are the ones that cause the problem, and my new build has worked
(so far from command line, from php not yet because i need to find the way to make slimerJS recognize the new version but that should be solved soon)

and the render works great with no crashes, so far i have tried with 4000 and 5000, later will try with more,

so i really think that the limit could perfectly be removed permanently

best
Any news on this? will the limit be removed soon? 
A higher limit will be needed by more and more developers in today's screen specs,
Thank you
dear Robert, any chance you could help make a patch for this issue? thanks so much
I doubt it, I only have access to Windows PCs.
oh ok no probs thank u Robert, i will keep waiting for somebody else that may want to help in here with this linux font size issue, thank u
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: