Closed Bug 191119 Opened 23 years ago Closed 18 years ago

Text looks the same size in Mozilla, but in other applications one is larger

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: u32858, Assigned: blizzard)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 This seems to be a mozilla problem, the text is the rong size Titles looking identical in Mozilla when one should be larger and does look larger when imported into a document. It seems strange that one is in the <tr> tag, but the other in the cell. --- <td><font size="+1"><big style="font-weight: bold;">Current Research and Development in Leisure Time</big><br> </td> <tr style="font-weight: bold;"> <td><font size="+1">Current interests in leisure time</font></td> </tr> --- Reproducible: Always Steps to Reproduce: 1.look at this html snippet or my CV on the URL above 2.opent the file in MS Word, or another wordprocessor 3. Actual Results: "Current Research and Development in Leisure Time" is the same size as the other text. Expected Results: It should be larger, as mozilla is making the text smaller than it should.
-->core
Component: Editor: Composer → Editor: Core
-->core
Assignee: composer → jfrancis
Anyone notice that nowere in the steps is the editor involved? reassigning....
.
Assignee: jfrancis → dbaron
Component: Editor: Core → Style System
QA Contact: sujay → ian
Worksforme on an Xft Linux build. Probably related to X core font selection. -> Gfx:Gtk.
Assignee: dbaron → blizzard
Component: Style System → GFX: Gtk
When I enlarge (zoom) the text then I see different sizes for "Current research and development" and "Current interests in leisure time" so the core font system will choose different sizes when they are available.
-> bstell for core font selection issues.
Assignee: blizzard → bstell
Chris, you proved you could trash/piss-on the core font code at will (you do remember getting your 10,000 line line trashing of the code approved by scc don't you) so I've backed off and only take on the issues I care to. -> blizzard
Assignee: bstell → blizzard
Yeah, and I'm still waiting for the huge flood of regressions and negative user comments as a result of that change where, you know, I moved code around. I guess that's the last time that I triage your bugs for you. *sigh*
as I remember rbs pointed out what a bad idea it was and then you gave up on the massive trashing > I guess that's the last time that I triage your bugs for you. My bugs? While I worked on the core font bugs for over 2 years, and even though I asked to be module owner, I was never was. > *sigh* You prove you (as one of the high priests) can piss on my work at will and you expect me to take direction from you. What kind of naive fool are you?
> as I remember rbs pointed out what a bad idea it was and then you gave up on > the massive trashing rbs gave me good feedback on the technical problems in the patch and offered a better path, which I took. I never got that from anyone else. > You prove you (as one of the high priests) can piss on my work at will and you > expect me to take direction from you. What kind of naive fool are you? a. I never pissed on your work. I'm not sure where you get this impression. b. I'm not offering any direction for your work, only my own.
Do you really want me to point out the multiple times you've pissed on my work? Because if your so unaware of doing this I'd be be happy to remind you. Or perhaps you could just look at the 100's of email we have exchanged about you trying to suppress or trash my work. Or I could remind you who you made sure Redhat rpm users could not even try my work.
> Do you really want me to point out the multiple times you've pissed on my work? > Because if your so unaware of doing this I'd be be happy to remind you. Or > perhaps you could just look at the 100's of email we have exchanged about you > trying to suppress or trash my work. Or I could remind you who you made sure > Redhat rpm users could not even try my work. I've said it before and I'll say it again. There's a good reason why I don't turn on FreeType (or Xprint for that matter.) I'm the one who has to support Mozilla in the Red Hat distribution. When crap breaks, I have to fix it. The more that Mozilla does, the more work it is for me. When someone asks for a piece of functionality, I have to trade that off against the possible costs to my time, and the time to my company and that includes long term support. Once FreeType is in the builds, people will expect it to work for some long period of time. I didn't and don't want to make that promise. A part of working in the open source world is this unspoken contract where if you are having a problem with a piece of code that you can generally contact the maintainer and he or she, within reason, will be able to support that code. I mean, lots of times, you're on your own but in general if a piece of code doesn't have a good owner, it's going to be replaced by something better because people don't like dealing with people who are hard to get along with, technical reasons aside. In the dealings that I've had with you, you've been pushy, unreasonable and very difficult to get along with. There's no way I'm going to put technology in the hands of my users that I know that I can't support in the long haul and where the upstream owner is entirely unreasonable. As for the email that you mention I have to say that sitting on this side of the fence I was never as you suggest. I did however suggest that you help hack on Xft instead of creating a similar system with only one app in mind. But you were in a hurry. So here we are. And you're angry about it. I'm sorry to hear that. But I can't let accusations as unfounded as this stand.
In mozilla's mission statement, http://www.mozilla.org/mission.html, "The Cathedral and the Bazaar" describes an important part of mozilla's philosophy: the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who'd take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles. The fact that this bazaar style seemed to work, and work well, came as a distinct shock. Tell me if I'm wrong but doesn't this describe a culture where input from multiple sources is allowed to compete? After I'd spent 2 years working to bring TrueType support to mozilla you, one of the high priests at mozilla, try to suppress it at the super-review stage. Xft dominance is so important to you that you don't want to allow any competition. You would rather nothing be allowed in until Xft is ready. So much for moz's philosophy. Your trying to suppress my work definitely made me unhappy. Having failed to suppress my work being checked in you, as a high priest at Redhat, made sure RPM users could not even try my work. You say you did this because you were worried about possible maintenance cost for a feature that is disabled by default and has no UI to enable it? Let me call your bluff. If I add a comment that tells users enabling this to report all font problems directly to me and not to Redhat and also ask system administrators not to turn this on. This way you won't get any bug reports for this code. Will you enable my code in the Redhat RPMs? If you do I'll gladly eat my words about you suppressing open source contribution. Go ahead show me who you really are. You suppressed my work be you _might_ see bugs. Today Mozilla and Netscape definitely actually do get stuck having this very burden for for your Xft work. Would you be okay if Mozilla and Netscape are set to not compile Xft in? Tell me what you really believe. What will you do when some other technology comes along that competes with Xft? Will you suppress that as well? By this point I was definitely unhappy with you but I let your suppression of my work in the Redhat RPMs go without complaining. I got really angry when you started to suppress on my printing project. You have no right to threaten to remove my FreeType code and doing so would rip out a core piece of the printing work. Now you are trying to suppress another of my open source contributions. This really made me angry. You then proved you could piss on my work at will when you began actually writing patches to add Xft. These patches had 16K lines of which 10,000+ lines had nothing to do with Xft but were a massive scrambling of my code. And then you get another high priest to review/approve it even though he had never worked in that code and even admits he has no idea what your patch is doing. I have never seen another case when the code developer explicitly disapproved of a patch but a super-reviewer, who admits not understanding it, marks it reviewed and another super-reviewer marked it super-reviewed. You say rbs just pointed out some technical issues? Over 10,000+ lines of technical issues? Either you made an awfully big mistake, or rbs and I are incredibly smart, or you were just having fun proving you could piss on my work at will. You find me pushy and hard to get along with? It is definitely much more than that. You have the advantage of being a high priest at mozilla and I'm just a regular contributor. I have become more and more angry as you repeatedly worked to suppress my work. Having had my work suppressed multiple times and pissed on by you I'm angry and it shows. You really are naive fool to think that after you've abused someone multiple times they will be kind and polite to you. I'm guilty of letting my anger that has built up as I've been abused multiple times on show in my comments. You are guilty of being a high priest who uses his privilege to suppress open source contributions.
> Tell me if I'm wrong but doesn't this describe a culture where input > from multiple sources is allowed to compete? Sure does. But it doesn't mean that I'm going to roll over if I think someone is making a mistake. Just because someone has written a patch to do something doesn't mean that it's OK to take it into a project. > > After I'd spent 2 years working to bring TrueType support to mozilla > you, one of the high priests at mozilla, try to suppress it at the > super-review stage. Xft dominance is so important to you that you > don't want to allow any competition. You would rather nothing be > allowed in until Xft is ready. So much for moz's philosophy. Your > trying to suppress my work definitely made me unhappy. I never tried to suppress your work. I sat on a super-review for a long time, partially because I was really busy at the time (and still am) and partially because I thought it was the wrong direction for the project to take (still do!) However, I never put my foot down and said no. It's in there, isn't it? > Having failed to suppress my work being checked in you, as a high > priest at Redhat, made sure RPM users could not even try my work. > You say you did this because you were worried about possible > maintenance cost for a feature that is disabled by default and has > no UI to enable it? Let me call your bluff. If I add a comment that > tells users enabling this to report all font problems directly to me > and not to Redhat and also ask system administrators not to turn > this on. This way you won't get any bug reports for this code. Will > you enable my code in the Redhat RPMs? If you do I'll gladly eat my > words about you suppressing open source contribution. Go ahead show > me who you really are. Hang on a second - do you work at Red Hat. Do you have to maintain the Mozilla package for Red Hat? I'm just curious because you create this false dichotomy between me having all the power at Red Hat and you having no power. And this is true. I have to maintain this package, I have to make the decisions about what to support and what not to support. But when it comes down to it, I also have to do the work to support it in the long term. When I add something, I sign up for making sure it works. I keep saying this over and over and you even say here "but it's without cost!" But that's just not true. Anytime that you add something, it has cost, be it in terms of code size or supportability, or whatever. Honestly, adding freetype into the Red Hat rpms means having to take the time to triage bugs to an upstream bugzilla to an already hostile owner. And I can't make the time to do that. I've got enough to do as it is. This isn't a game of poker. You don't get to call my bluff, because I'm not playing any games. I don't think that what you have in the tree is as good as what Xft offers and is seriously lacking in some technical respects. I'm not going to ship it because it doesn't add enough value to offset its costs. You want to know who I am? I'm the guy who has to package this up for Red Hat's millions of users, who has to keep the project working well on Red Hat's platform, make sure that it works on other people's platforms too, try to make sure that mozilla.org doesn't make too many bad mistakes from a techinical direction and that people know about our little project and that it's a good idea to use it. That's me. From your writings here you see me as some sort of evil genius, but without the genius part. I can assure you that I'm neither evil, nor particularly genius-like. > You suppressed my work be you _might_ see bugs. Today Mozilla and > Netscape definitely actually do get stuck having this very burden > for for your Xft work. Would you be okay if Mozilla and Netscape are > set to not compile Xft in? Tell me what you really believe. And I pay for the burden of your freetype work. It has little value to me, but the code is still there. Eating disk space and network bandwith every time I have to update my tree. But because I can turn it off, I'm OK with it. You can do the same thing. I'm not sure why you get to be pissed off about having to pay the cost for my code and I'm not allowed to be pissed off for paying the cost of yours. Are Mozilla and Netscape compiling with Xft enabled? No. Do you hear me screaming bloody murder to have them start using it? Not really. It's good for Red Hat and our users, though. > What will you do when some other technology comes along that > competes with Xft? Will you suppress that as well? Ask me when one shows up that actually competes. (Just wait till you see Xr!) > By this point I was definitely unhappy with you but I let your > suppression of my work in the Redhat RPMs go without complaining. I > got really angry when you started to suppress on my printing > project. You have no right to threaten to remove my FreeType code > and doing so would rip out a core piece of the printing work. Now > you are trying to suppress another of my open source contributions. > This really made me angry. Hang on a second - why do you get to say what goes into Red Hat and what doesn't? I'm just curious, because you keep coming back to this supposed right. This is open source. I get to pick and choose, because the license allows me. Red Hat doesn't have to ship your stuff, and Netscape doesn't have to ship mine. It's as simple as that. And I'm not sure where you get this "started to suppress on my printing project" bit (is that english?) > > You then proved you could piss on my work at will when you began > actually writing patches to add Xft. These patches had 16K lines of > which 10,000+ lines had nothing to do with Xft but were a massive > scrambling of my code. And then you get another high priest to > review/approve it even though he had never worked in that code and > even admits he has no idea what your patch is doing. I have never > seen another case when the code developer explicitly disapproved of > a patch but a super-reviewer, who admits not understanding it, marks > it reviewed and another super-reviewer marked it super-reviewed. The code developer who disapproved of the patch in this case was...you? Who else thought it was such a terrible idea? And apparently a couple of other super-reviewers thought it was a good idea because they were willing to put their mark on it. Also, I'm not sure who you are talking about here (feel free to use names, I'm sure they won't mind) but they should be not marking super-reviews if they don't understand something. That's their problem, not mine. I was bugging super-reviewers to review the patch, but that was because it needed to be done and I wanted the patch to get in sooner rather than later. You're looking for some sort of conspiracy here but there isn't one, really. Besides, the changes in question were really in the new Xft code, not in the core code which, although being shuffled a bit, didn't really suffer from any logic changes. You know, when I went out to get reviews, I tried to be extra careful to make sure that I wasn't taking advantage of my position in order to ram a patch through the system. Apparently I failed at that, even though I played by all the rules. > You say rbs just pointed out some technical issues? Over 10,000+ > lines of technical issues? Either you made an awfully big mistake, or > rbs and I are incredibly smart, or you were just having fun proving > you could piss on my work at will. Oh, please. You keep throwing this number around with all its zeros like you're saying one MILLION dollars and you had your pinky in the corner of your mouth. The simple fact is that all that 10,000 lines was just cut-n-pasted around. That's it. No changes to logic, just location. If patch were smarter, it would have seemed much smaller. That being said, rbs had some good ideas about how to make things simpler. And they made sense. I never say anything like that from you. > You find me pushy and hard to get along with? It is definitely much > more than that. You have the advantage of being a high priest at > mozilla and I'm just a regular contributor. I have become more and > more angry as you repeatedly worked to suppress my work. Having had > my work suppressed multiple times and pissed on by you I'm angry and > it shows. You really are naive fool to think that after you've > abused someone multiple times they will be kind and polite to you. > I've never abused you and I've never suppressed your work as you would describe it. I have said a few times that I thought that the work that you were doing was taking the project in the wrong position from a techinical standpoint, and I still think that, fwiw. I'm sorry if that offends you but I wouldn't be doing my job if I didn't say anything. > I'm guilty of letting my anger that has built up as I've been > abused multiple times on show in my comments. > > You are guilty of being a high priest who uses his privilege to > suppress open source contributions. Sorry that you feel that way. I don't. I'm annoyed that I keep having to post messages like this to explain the same things over and over and over again, but I hold no animosity. If I had to go back and do things differently about the only thing I would have done was to get my copy of the big purple book a few months earlier. Other than that I'm still confident I've made the right choices.
> However, I never put my foot down and said no. It's in there, > isn't it? You tried your best to suppress it. In the end it was Brendan that allowed forced the issue. > this false dichotomy between me having all the power at Red Hat > and you having no power You words: "I have to make the decisions about what to support and what not to support". Your words: "I get to pick and choose". Would you kindly let me know what power I have at Redhat? > adding freetype into the Red Hat rpms means having to take the > time to triage bugs to an upstream bugzilla Again, did you forget it is disabled and there is no UI to enable it? > to an already hostile owner I was not hostile before you began trying to suppress my work. > I pay for the burden of your freetype work ... Eating disk space > and network bandwith every time I have to update my tree ... I'm > not sure why you get to be pissed off about having to pay the cost > for my code Remind me when I complained about the disk/network cost for your code being in the tree? > > What will you do when some other technology comes along that > > competes with Xft? Will you suppress that as well? > Ask me when one shows up that actually competes. The direct FreeType code can print the TrueType fonts. Isn't this an important issue to users? Isn't this competition? Yes, I know that there a post filters that can embed TrueType after the app has rendered it but that means that the app has to guess the metrics. What about STSF? It is purported to have higher display performance, better system memory usage, and it supports printing. Do we allow it or do we suppress it? > (is that english?) If you would like I will be happy to point out your grammer and spelling error but it seems off topic. > I'm not sure who you are talking about here ... but they should be > not marking super-reviews if they don't understand something. I did not complain about the super-review. Correct me if I'm wrong but reviewer needs to understand the code. Would you kindly point out where scc ever worked on the font part of the font code? > The code developer who disapproved of the patch in this case > was...you? Who else thought it was such a terrible idea? Yes, I disapproved of the 10,000 lines that were unrelated to Xft and rbs said "mess with it [the core X font code] as little as possible" after which your patch suddenly got 10,000 lines smaller as I had been requesting for over a month. > You know, when I went out to get reviews, I tried to be extra > careful to make sure that I wasn't taking advantage of my position > in order to ram a patch through the system. As a super-reviewer you should know that the reviewer needs to understand the code. You should have declined scc's review. > rbs had some good ideas about how to make things simpler. And > they made sense. I never say anything like that from you. You missed these? > ------- Additional Comment #63 From Brian Stell 2002-08-13 09:45 ------- > Most of patch looks like it is not directly needed for Xft. > This obscures the Xft changes. > Separating out the Xft changes from the reorg would make it much easier for > people to see what you are actually doing that is Xft related. > > ------- Additional Comment #64 From Brian Stell 2002-08-13 09:54 ------- > > As it stands now this patch makes significant non-Xft related changes to the > font subsystem. > > Perhaps you could separate this into a separate bug so it can be discussed > separately from the Xft issues. > > Before any one codes up a massive change to the font subsystem I would hope > that we would give other developers time to add their input. I am fairly > positive that other font developers may have thoughts and it seems reasonable > to include, communicate, and coordinate with them. I believe we may find that > they have > > 1) other goals and directions > 2) other work in progress > 3) other planned work > 4) other requested work/features > > It would also be good to discuss the particulars of the changes implied in > this patch: > > 1) the extent and goals of this particular change > 2) how this particular significant fits the font subsystem architecture > 3) how to manage any possible negative user impact > > I'm still confident I've made the right choices. It must be nice to feel omniscient. Its very clear that the point I've been trying to make: "the open souce philosophy encourages multiple solutions" is lost on you. > I hold no animosity. Sure, just like Bill Gates holds no animosity to the companies he's crushed. However, the feelings from the other side is not the same.
>> this false dichotomy between me having all the power at Red Hat >> and you having no power > > You words: "I have to make the decisions about what to support > and what not to support". Your words: "I get to pick and choose". > > Would you kindly let me know what power I have at Redhat? That was my entire point. That you being upset at me for not shipping your code as part of Red Hat's distribution isn't really reasonable - that's not your decision to make. >> adding freetype into the Red Hat rpms means having to take the >> time to triage bugs to an upstream bugzilla > > Again, did you forget it is disabled and there is no UI to enable it? If there's UI, I have to support it. If it's there and there's no UI, I still have to support it. > The direct FreeType code can print the TrueType fonts. Isn't this > an important issue to users? Isn't this competition? Yes, I know > that there a post filters that can embed TrueType after the app > has rendered it but that means that the app has to guess the metrics. Yep. Totally a problem, but not something that would prevent me from shipping Xft or something that can't be fixed. That's why bug 190031 exists. I was waiting for you guys to finish up the code that would allow you to embed the font bitmaps into the postscript output. Then I was going to hook up Xft's font selection mechanism into the postscript code (or call back out to the xft font metrics code - I haven't worked this out at length.) Should be pretty simple. > > What about STSF? It is purported to have higher display performance, > better system memory usage, and it supports printing. Do we allow > it or do we suppress it? Waiting for patches and wide distribution of the mechanisms and viability. I've also heard that it requires patches to clients _and_ servers which doesn't make it really viable for the kind of hetergeneous environments that I have to play in. >> (is that english?) > > If you would like I will be happy to point out your grammer and > spelling error but it seems off topic. Oh, geez. I was just having fun. >> I'm not sure who you are talking about here ... but they should be >> not marking super-reviews if they don't understand something. > > I did not complain about the super-review. Correct me if I'm wrong > but reviewer needs to understand the code. Would you kindly point > out where scc ever worked on the font part of the font code? Actually, super-review doesn't have to express domain knowledge. They only have to worry about the quality, its structure and if it fits into the entire "mozilla picture." A regular review has to be done by someone with domain knowledge. That's why I asked rbs to do a review. > Yes, I disapproved of the 10,000 lines that were unrelated to > Xft and rbs said "mess with it [the core X font code] as little as > possible" after which your patch suddenly got 10,000 lines smaller > as I had been requesting for over a month. [ More on this below. ] > >> You know, when I went out to get reviews, I tried to be extra >> careful to make sure that I wasn't taking advantage of my position >> in order to ram a patch through the system. > > As a super-reviewer you should know that the reviewer needs to > understand the code. You should have declined scc's review. I asked him to review. > >> rbs had some good ideas about how to make things simpler. And >> they made sense. I never say anything like that from you. > > You missed these? > > > ------- Additional Comment #63 From Brian Stell 2002-08-13 09:45 ------- > > Most of patch looks like it is not directly needed for Xft. > > This obscures the Xft changes. > > Separating out the Xft changes from the reorg would make it much easier for > > people to see what you are actually doing that is Xft related. > > > > ------- Additional Comment #64 From Brian Stell 2002-08-13 09:54 ------- > > > > As it stands now this patch makes significant non-Xft related changes to the > > font subsystem. > > > > Perhaps you could separate this into a separate bug so it can be discussed > > separately from the Xft issues. > > > > Before any one codes up a massive change to the font subsystem I would hope > > that we would give other developers time to add their input. I am fairly > > positive that other font developers may have thoughts and it seems reasonable > > to include, communicate, and coordinate with them. I believe we may find that > > they have > > > > 1) other goals and directions > > 2) other work in progress > > 3) other planned work > > 4) other requested work/features > > > > It would also be good to discuss the particulars of the changes implied in > > this patch: > > > > 1) the extent and goals of this particular change > > 2) how this particular significant fits the font subsystem architecture > > 3) how to manage any possible negative user impact Oh, now we're quoting? _awesome_. I'll just paste this very relevant comment: > > ------- Additional Comment #257 From rbs@maths.uq.edu.au 2002-10-07 08:36 ------- > > blizzard asked me to act as reviewer for his patch. I have been travelling and > it is just now that I am having a chance to dig into the patch. Reading the > numerous comments ate plenty of the time. It is however unfortunate that most of > these weren't constructive comments. There were some points that bstell made and > which blizzard responded adequately (comment 94), and this seemed to have > essentially provided a point of consensus: separate Xft support although bstell > isn't totally agreable with all the nitty-gritty details -- without > unfortunately being as constructive as he was in bug 132759. bstell, since you > obviously have a vested interest on fonts, and Xft is poised to supersede what > you did (at some stage), you could have iterated on the proposed patch (as you > did in bug 132759) to contribute your desired alterations for others to chew > upon. Only blizzard's patch is here for us to review. > also: > > ------- Additional Comment #285 From rbs@maths.uq.edu.au 2002-10-08 21:56 ------- > > OK, I have read the patch and see the motivation of what the patch is doing > (comment 125 and comment 164). Other reviewers have caught most of the edgy > stuff, but there is remaining architectural point which might greatly simplify > the patch (and ease maintainance of both codes and the the final switch over to > Xft). [...] > > There can be a dispatch mechanism in gfx/src/gtk/nsGfxFactoryGTK.cpp. > With that, it would be possible to setup nsFontMetricsXftGTK (or some other > name), and override the default behavior in nsGfxFactoryGTK.cpp, e.g., by doing: That's what I'm talking about when I say rbs gave me something specific to work with. Look at your comments above. They are very generic. rbs gave me a real honest-to-god method for making it possible not to have to change a lot of lines of code. >> > >> I'm still confident I've made the right choices. > > It must be nice to feel omniscient. Its very clear that the point I've been > trying to make: "the open souce philosophy encourages multiple solutions" is > lost on you. I certainly don't feel omniscient. Never have, never will. I still stub my toe on small curbs. And I completely understand that we have multiple solutions in open source software. I also understand that we have multiple solutions and that sometimes they compete with each other. I've chosen what's right given Red Hat's (and lots of other linux vendor's) specific needs. You confuse arrogance with confidence and a different set of priorities. >> I hold no animosity. > > Sure, just like Bill Gates holds no animosity to the companies he's > crushed. However, the feelings from the other side is not the same. > If you could see me right now I would be rolling my eyes.
> >> this false dichotomy between me having all the power at Red Hat > >> and you having no power > > > Would you kindly let me know what power I have at Redhat? > > That was my entire point. That you being upset at me for > not shipping your code as part of Red Hat's distribution > isn't really reasonable - that's not your decision to make. The point was and still is: you have the inside connection at Redhut and I none. > If there's UI, I have to support it. If it's there and there's > no UI, I still have to support it. Sure, and if its disabled, has no UI to enable it, and no Redhat documentation on how to enable it will really be a big issue. > > The direct FreeType code can print the TrueType fonts. Isn't > > this an important issue to users? Isn't this competition? > Yep. [Printing is] Totally a problem, but not something that > would prevent me from shipping Xft or something that can't be > fixed. That's why bug 190031 exists. Its clear that even important issues like printing don't matter to you. So much for even the pretense of competition. > > What about STSF? It is purported to have higher display performance, > better system memory usage, and it supports printing. Do we allow > it or do we suppress it? > > Waiting for patches and wide distribution of the mechanisms and > viability. I've also heard that it requires patches to clients _and_ > servers Funny, those were *exactly* the problems with Xft when you first began my code should not be even allowed into the moz tree. Would you kindly explain why Xft didn't need to meet those to be viable but STSF does? > A regular review has to be done by someone with domain knowledge. Which is why accepting scc's 'r=' was so wrong (especially for a senior team member who know's better). You clearly accepted scc's review on 2002-10-07 when you carried it forward. Even a cursory look at the file logs shows that scc has not done any significant work in those files. Accepting his 'r=' was wrong on your part. You should have declined scc's 'r=' but it was clear proof you could piss on my work. rbs pointed out that the 10,000 extra lines were unnecessary (exactly as I had). > I'll just paste this very relevant comment: Sure, rbs points out we are having a fight. As I have no problem denying I was angry after your 3rd suppression of my work and your proof you could piss on it at will. It shows in the comments. > Sure, just like Bill Gates holds no animosity to the companies he's > > crushed. However, the feelings from the other side is not the same. > > > > If you could see me right now I would be rolling my eyes. You used your inside position to prevent any competition. You still are and based on your clear double standards it looks like you will continue to do so.
>> That was my entire point. That you being upset at me for >> not shipping your code as part of Red Hat's distribution >> isn't really reasonable - that's not your decision to make. > > The point was and still is: you have the inside connection at > Redhut and I none. I'm really confused here. How does my position within Red Hat affect your ability to check code into the Mozilla tree? Or get reviews from non-Red Hat people? >> Yep. [Printing is] Totally a problem, but not something that >> would prevent me from shipping Xft or something that can't be >> fixed. That's why bug 190031 exists. > > Its clear that even important issues like printing don't matter > to you. So much for even the pretense of competition. That's funny. Your FreeType code was in a long time ago. This printing code only landed recently. So you've only cared recently? I'm just curious. >> > What about STSF? It is purported to have higher display performance, >> better system memory usage, and it supports printing. Do we allow >> it or do we suppress it? >> >> Waiting for patches and wide distribution of the mechanisms and >> viability. I've also heard that it requires patches to clients _and_ >> servers > > Funny, those were *exactly* the problems with Xft when you first > began my code should not be even allowed into the moz tree. > > Would you kindly explain why Xft didn't need to meet those to be > viable but STSF does? Xft works against servers that doesn't support RENDER. My understanding is that STFT doesn't. Also, I have yet to see any client implementations of STFT shipping with any vendors. > >> A regular review has to be done by someone with domain knowledge. > > Which is why accepting scc's 'r=' was so wrong (especially for > a senior team member who know's better). > > You clearly accepted scc's review on 2002-10-07 when you carried it > forward. Even a cursory look at the file logs shows that scc has > not done any significant work in those files. Accepting his 'r=' > was wrong on your part. You should have declined scc's 'r=' but > it was clear proof you could piss on my work. I don't think that scc meant to review it in such a way as to indicate domain knowledge. It was just a review. That's why I still went to rbs. I wouldn't have gone ahead without a review from one of the font folks. > > rbs pointed out that the 10,000 extra lines were unnecessary (exactly > as I had). Yeah, but in a way that wasn't just whining - he actually offered a path to fix it. Basically, he cared. > Sure, rbs points out we are having a fight. As I have no problem > denying I was angry after your 3rd suppression of my work and > your proof you could piss on it at will. It shows in the comments. Still rolling the eyes here. > >> Sure, just like Bill Gates holds no animosity to the companies he's >> > crushed. However, the feelings from the other side is not the same. >> > >> >> If you could see me right now I would be rolling my eyes. > > You used your inside position to prevent any competition. You still > are and based on your clear double standards it looks like you will > continue to do so. *shrug* I'm sorry that you still continue to see things that way. That was never the case and I was quite careful not to "abuse my position" as you claim. Ask anyone I talked to during that period. I was clear that I a module peer review. I needed super-review. Just like you did. Check it out - we had to follow the same process and did.
> Your FreeType code was in a long time ago. This printing code > only landed recently. So you've only cared recently? I'm just > curious. Over 2 years ago I've been saying that printing needed to be part of any new font display work. Any new "font display standard" (including Xft) that does not address printing at its core just continues Unix/Linux's failure in this area. Yes, there was a year between the direct FreeType display code and the printing code. I put a huge amount of work into printing during this time. I spent a long time considering where I wanted to end up. Xprint has the same speed-of-deployment problem that has caused core X fonts to always be years behind. As long as apps have to wait for server upgrades before they can use new features there will be significant delays in getting these features to users. Hence the decision to handle printing at the client side. The next issue is how to support mulitple printer types. It is very desirable for an app to have one API that can render to a large variety of printers. Windows seems to have a meta language that can be converted to the what the printer needs. The only technology in the Unix/Linux domain which I found that allows an app to do generic rendering and that also works with a large range of printer is render-Postscript and let Ghostscript convert for the printer. The next issue was international language support. The Unix/Linux postscript printing code I saw could either didn't handle large character sets at all or broke the large character set fonts into mutiple small fonts typically scrambling the encoding. This forces the app to keep some sort of lookup table of which subfont a particular character was and then to frequently switch the subfont to get access to a given character. The next issue was learning to embed fonts in Postscript. I learned how to embed Truetype fonts. I also spent time and learned how to subset TrueType fonts so when they were embedded as Type42 or Type11 the printout would not have multiple megabytes of unneeded glyph outlines when CJK fonts were being used. So I could make an informed decision about the tradeoffs with other Postscript font encodings I spent time to learned and wrete code to to convert Truetype to Type1, Type3, Type8, and Type9 fonts. Another issue that took time was getting the Sun engineers in Bejing to interested in developing and supporting printing.
gfx/src/gtk/ has been removed on trunk and so has Xprint support. This bug has to much unrelated noise in it. Please file a new bug if the problem still occurs in a recent trunk build. Thanks. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ -> WORKSFORME
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.