Weekly Edition
Return to the Announcements page
| |||||||||||||
Monomania (Tux Deluxe)
Here's a look at Mono by Jeremy Allison on the Tux Deluxe site. "But my basic issue with the Microsoft Community Promise is that Miguel doesn't have to depend on it like everyone else does. Miguel's employer, Novell, has a patent agreement with Microsoft that exempts Mono users from Microsoft patent aggression, so long as you get Mono from Novell. Miguel takes pains to point this out. This is not a level playing field, or software freedom for all. This is a preferred supplier trying to pretend there is no problem. Sure there isn't a problem, for them. If it isn't good enough for Miguel, why is it good enough for other developers?"
(Log in to post comments)
Monomania (Tux Deluxe) Posted Oct 15, 2009 15:13 UTC (Thu) by laurencevde (guest, #61381) [Link]
Just "too bad" for novell that MS's "covenant not to sue" contains quite a
large list of excluded products (gross simplification): Clone products that are created(or got new functionality) after that covenant was put in effect, or are called Wine, OpenXchange, StarOffice or OpenOffice. Hosted Office-applications, gaming-stuff, business-apps, mail-servers, and "unified communications".
Mono can most probably be put in MS's definition of "clone products"...
http://www.microsoft.com/interop/msnovellcollab/patent_ag...
Monomania (Tux Deluxe) Posted Oct 15, 2009 16:09 UTC (Thu) by leomilano (guest, #32220) [Link]
Nasty stuff! In the meantime, RedHat keeps a strong leadership in the server, and I am starting to move my desktops to purely Qt/KDE installs (to avoid any Mono contamination).
Monomania (Tux Deluxe) Posted Oct 15, 2009 16:16 UTC (Thu) by proski (subscriber, #104) [Link] There is no need to switch to KDE to avoid Mono. All you need to do is
yum remove "mono*"
The dependency of GNOME on Mono is greatly exaggerated.
Monomania (Tux Deluxe) Posted Oct 15, 2009 20:25 UTC (Thu) by dmarti (subscriber, #11625) [Link] Feel free to borrow and work from the antipackages--the general idea is to install "no-mono" to make the package manager warn you if you bring in something that depends on it. (Also antipackages for no-java, no-python, to be fair.)
Monomania (Tux Deluxe) Posted Oct 16, 2009 0:04 UTC (Fri) by proski (subscriber, #104) [Link]
Nice idea! It would be great to have it in rpm format as well. Those who prefer to compile their own kernels might want an "antikernel".
Monomania (Tux Deluxe) Posted Oct 16, 2009 1:01 UTC (Fri) by drag (subscriber, #31333) [Link]
You don't need a antipackage and you don't need to deal with that when you
compile your kernel.
When installing software use aptitude and when you install a bunch of crap
For custom kernels you use kernel-package and you can easily create your
If you want to you can compile everything from source using the dpkg/apt-
Monomania (Tux Deluxe) Posted Oct 16, 2009 1:52 UTC (Fri) by dmarti (subscriber, #11625) [Link] Sure, you don't _need_ the antipackage, but it converts something you have to check for into something that fails.
Monomania (Tux Deluxe) Posted Oct 16, 2009 3:14 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
If you want to exclude any packages, you can do something like exclude=foo* in /etc/yum.conf. I am not sure I understand the benefit of short circuiting the dep resolver.
Monomania (Tux Deluxe) Posted Oct 15, 2009 17:35 UTC (Thu) by AlexHudson (subscriber, #41828) [Link]
I still don't understand the fuss about the Novell agreement.
If Mono has a patent problem, it's going to be Novell who get sued. Putting in place an agreement which ensures customers don't get sued (by one party) - not particularly fair, but not particularly a freedom problem. Novell are still at risk.
Arguing that Mono should be put in a "restricted" category doesn't make any sense. It's not like the patents at issue (which never seem to be properly defined) aren't going to cover other software.
Monomania (Tux Deluxe) Posted Oct 15, 2009 17:52 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
Novell would not get sued, they have a seperate agreement with microsoft saying that microsoft will not sue them. The people who would get sued are the people who use any linux distro other than novell that uses mono.
Monomania (Tux Deluxe) Posted Oct 15, 2009 18:08 UTC (Thu) by AlexHudson (subscriber, #41828) [Link]
I'm not convinced you're able to cite an agreement between the two which covers *Novell* (not their customers). That's certainly not what Jeremy seems to be claiming.
Monomania (Tux Deluxe) Posted Oct 15, 2009 23:24 UTC (Thu) by coriordan (guest, #7544) [Link]
I think I'm missing something. Why would anyone cite the agreement? Is the problem that the agreement is useless (because it's too narrow and there are too many exceptions)?
So the agreement is useless, MS owns a heap of patents on this thing, and Novell and de Icaza are trying to convince us we should use it as the foundation for our software.
How is there not a problem there?
Maybe we can't avoid all potentially dangerous software, but this stack's a real stinker. We could at least avoid this one.
Monomania (Tux Deluxe) Posted Oct 16, 2009 8:06 UTC (Fri) by AlexHudson (subscriber, #41828) [Link]
No, what I was saying was simpler than that.
The agreement is public knowledge, and it's on Novell's and Microsoft's website. It's well known that they covered each other's customers.
The claim above that I don't think can be supported is that Novell themselves are covered by that agreement. I've never read anyone before seriously suggest that, and that situation would definitely put them in trouble with their obligations under the GPL.
Monomania (Tux Deluxe) Posted Oct 16, 2009 9:03 UTC (Fri) by BeS (subscriber, #43108) [Link] >It's well known that they covered each other's customers. Let's try a syllogism:
Monomania (Tux Deluxe) Posted Oct 16, 2009 10:43 UTC (Fri) by AlexHudson (subscriber, #41828) [Link]
I'm sure I don't need to point out the error on logic in the above :), but it's irrelevant anyway: the promise not to sue is offered by MS, but not tied to the software (it's not a license). MS say "we won't sue Novell's customers" - where Novell got "their" copy of Mono from is inconsequential, the promise doesn't apply to them.
Monomania (Tux Deluxe) Posted Oct 16, 2009 12:10 UTC (Fri) by pebolle (guest, #35204) [Link]
> the promise not to sue is offered by MS, but not tied to the software (it's not a license)
0) Why isn't it a license?
1) In case the fact that this document (declaration? whatever?) is called a promise not to sue is relevant for the answer to that question: the GPL could also be rewritten as a promise not to sue (with sufficient abuse of legalese) without changing its effects. I'd say that (hypothetical) GPL rewritten as a promise not to sue should still be regarded as a license.
Actually, I'd think that in general a lot of contracts, licenses, etc. can be rewritten negatively (eg, as a promise not to sue): that would not change their effects (but the parties involved are then forced to use documents with really, really ugly legalese).
Monomania (Tux Deluxe) Posted Oct 16, 2009 12:29 UTC (Fri) by epa (subscriber, #39769) [Link]
The distinction between a promise-not-to-sue and a licence is the main reason why some (such as the FSF) are unhappy with Microsoft's 'community promise' not to sue over the software patents they hold that apply to C# and the CLR. Whereas a licence is generally irrevocable unless it states otherwise, you could possibly get out of a promise-not-to-sue by passing on the patents to another company which is not bound by your promise.
Indeed, promises in general are not binding; if I promise to pay you a dollar tomorrow, you have no recourse if I break it. However the doctrine of promissory estoppel means that if I promise to allow use of certain property rights and you take action based on that promise, I cannot then break the promise and sue you. IANAL, so that's the limit of my knowledge, but I do know that there is a difference between a promise and a licence, and while it may be legalese, it's the kind of legalese that makes a difference in some cases.
(So, then, back to the 'community promise' offered by MS to people who are not Novell customers: I don't share the FSF's concerns, since it seems to me pretty hard to persuade a court that you can get out of it, even if the patents were transferred to a third party. I would expect a patent suit from a third party to be estopped just as much. But the FSF's lawyers take a more cautious view and think that only a true licence will make sure of this. (Then again, I was happy to use and distribute Mono even before this 'community promise', since there is plenty of software which implements software patents, some of which are even held by Microsoft, and I see no reason to pre-emptively cringe and go begging to patent-holders in advance for every program we want to write. Let them sue, if they dare.))
Monomania (Tux Deluxe) Posted Oct 25, 2009 8:10 UTC (Sun) by malor (subscriber, #2973) [Link]
It's important to understand that there's a reason for not specifically pointing out the patents: knowing infringement of a patent exposes you to treble damages in a court case.
If you tell a developer, "Mono violates Microsoft patents, and you could be sued", that's just a warning. If you say, "Mono violates Microsoft patent #foo when it uses this particular trick to compile code at runtime", you have now put them in a tight spot; they have to remove the offending code immediately or be three times as exposed if the issue ever goes to court. The person doing the research becomes 'polluted', and anyone he or she communicates that research to is polluted as well. It can be argued (and probably would be) that if anyone on a software project team knew about the patents, then the entire project is liable for treble damages. So you've instantly forced the project to either remove code, or drop poisoned developers.
That's why you see it always painted obscurely, instead of as specific documentation, because if they document it, and you read it, you're screwed. Since they're trying to help you, not hurt you, they stay as obscure as they can. It's FUD, but it's FUD for your benefit, not to confuse you into making bad decisions.
Monomania (Tux Deluxe) Posted Oct 25, 2009 8:17 UTC (Sun) by malor (subscriber, #2973) [Link] Crap, I should have included this quote in the post above:It's not like the patents at issue (which never seem to be properly defined) My reply isn't to the main point of your post, but rather to the 'never properly defined' comment. There's a reason why the handwringing is mostly noise and not much signal... it's deliberate, to protect everyone involved.
Re: Only Novell will get sued Posted Oct 15, 2009 17:55 UTC (Thu) by PO8 (guest, #41661) [Link]
IANAL, but I don't think you understand how patents work. A patent holder can sue anyone who "practices" her patent without a license. Whether someone who compiles or even just runs a C# program using unlicensed Mono "technology" is practicing Microsoft's patents that bear on C# and .Net is a matter for courts to decide; I don't know how they would rule. In any case, I can't afford to be sued, even if I might eventually prevail.
So as far as I can tell it's not merely Novell's problem. Until Microsoft officially licenses its Mono-related technologies without restriction to the open source community (and for me the "Community Promise" doesn't count), I will personally be keeping Mono at arm's length.
Honestly, it isn't proving very hard for me to live without C# and .Net in my open source work anyhow.
Re: Only Novell will get sued Posted Oct 15, 2009 18:07 UTC (Thu) by AlexHudson (subscriber, #41828) [Link]
The "can't afford to be sued" argument is ok as a personal decision, but as a general rule for the community we'd have very little software after we avoided anything with a credible legal threat (which, if you can't use Mono, would certainly include Java and most other VM-based languages).
I'd love to see some citation for being sued by the patent holder for being the beneficiary of patent infringement in someone else's software though. (if you're "practising the patent" directly, it doesn't matter what language you've implemented it in - going to e.g. Python doesn't get you out of that jail).
No need Posted Oct 15, 2009 20:20 UTC (Thu) by ncm (subscriber, #165) [Link]
Fortunately, most of us have no need to run any Java program, either. Indeed, if we did have a Java program we needed, we would have no need to run it on a VM.
No need Posted Oct 15, 2009 20:48 UTC (Thu) by drag (subscriber, #31333) [Link]
You'll need the Sun Java JRE (or equivelent) for simple compatibility purposes for most software. GCJ does not cut it by itself.
Luckily the next java version will be fully open source, I believe.
No need Posted Oct 16, 2009 1:34 UTC (Fri) by mikov (subscriber, #33179) [Link]
?? There is a fully open source Java version right now - it is called OpenJDK. It is available in Debian main - is there a stringer guarantee for being free? :-) :-)
BTW, I am have found some minor incompatibilities, but it is almost certainly good enough.
No need Posted Oct 16, 2009 3:18 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
OpenJDK in Fedora is certified by TCK to be 100% compliant. So if there are problems with applications, either the application is buggy or tck needs more tests
No need Posted Oct 16, 2009 4:17 UTC (Fri) by mikov (subscriber, #33179) [Link]
I remember seeing two problems. One was related to SSL, and the other to font rendering. The latter is understandable, naturally, but it still should be acknowledged. The former is a bit more troublesome - alas I didn't have time to investigate it, but I noted that the application wouldn't work.
No need Posted Oct 16, 2009 4:42 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Perhaps you can file bug reports or let me know the application names.
No need Posted Oct 17, 2009 2:30 UTC (Sat) by mikov (subscriber, #33179) [Link] The font rendering is obvious in Swing applications, in IntelliJ IDEA specifically. It looks different and arguably worse when run under OpenJDK. As I said, that is understandable and perhaps even desirable because it is more consistent with font rendering in native apps, but it does look visibly different from Java applications on Windows. Arguably, that breaks Java's promise of portability. The more serious SSL problem was seen in an app developed by our company. I am not an expert in SSL or its Java implementation so I can't make head or tails of it. It is in a straight forward call to HttpURLConnection.connect(). This is the stack trace:
No need Posted Oct 22, 2009 9:01 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Java font rendering is crap (probably one of the main reasons it never went anywhere on the desktop). The sooner the openjdk people manage to extirpate all traces of the old SUN font code from openjdk, and switch to normal font libraries (fontconfig, pango, cairo, which *have* proven themselves in major desktop apps like Firefox), the better it will be.
Right now most Linux font bugs read like "it works great in GNOME, so-so in KDE/QT (because it lags pango/cairo in adoption of new font features), it is broken in OO.o (because it inherited from SUN custom text rendering libs, and has not finished migrating to cairo yet), and hopeless in Java"
No need Posted Oct 22, 2009 16:47 UTC (Thu) by nye (guest, #51576) [Link]
I can't recall ever noticing any difference in font rendering between GTK and Qt apps, besides perhaps the choice of default font (so not actually a rendering issue). In what way might the fonts in Qt applications be worse?
No need Posted Oct 22, 2009 17:50 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Typically, support of new OpenType features and Unicode processing in languages that use non-trivial scripts (ie not English). QT usually lags some behind gtk/cairo.
Rendering is only a very small part of text/font support. Since both GTK and QT use freetype for rendering (but differ higher up in the stack) you won't see rendering differences on the same system (with the same system-wide freetype)
No need Posted Oct 22, 2009 16:58 UTC (Thu) by mikov (subscriber, #33179) [Link]
Java font rendering looks fine to me, and anyway the really important thing is that it looks the same everywhere.
Secondly, font rendering in Linux, with what you call "normal libraries" has some pretty serious problems. For example it looks absolutely horrible without anti-aliasing and small font sizes.
I understand why Sun's font rendering has to be replaced, but we can't pretend that the above two problems don't exist.
No need Posted Oct 22, 2009 17:28 UTC (Thu) by nye (guest, #51576) [Link]
>For example it looks absolutely horrible without anti-aliasing and small font sizes.
That's not so much the rendering, as the fonts (and the patent issue, in cases where you have well-hinted fonts but are stuck with the autohinter). Open-source fonts are all designed to be heavily anti-aliased, so they aren't well hinted.
I use Microsoft fonts and enable antialiasing for point sizes < 8 and > 14, and I'm very happy with the result as long as I blacklist a handful of fonts that I hate but can't uninstall for silly package dependency reasons.
If you're hoping for better rendering at size 6 with no anti-aliasing, then you'd better have some extraordinarily well-hinted fonts I think, and the patented bytecode interpreter enabled.
No need Posted Oct 22, 2009 18:27 UTC (Thu) by mikov (subscriber, #33179) [Link]
I am not really complaining about regular desktop usage - my Linux desktop actually looks fine to me; although perhaps some of that is force of habit. I don't deal with visual design, so I am OK as long as it is just acceptable.
But occasionally I notice problems:
- Even though I have the Microsoft fonts, web pages in Firefox look different in Windows (and arguably better, although it is naturally subjective).
- If I disable anti-aliasing completely in the desktop it becomes really horrible. Of course there is no reason to do it, except as an experiment. But it is still depressing. Windows 2000 really looks beautiful and crisp by comparison. As I said, depressing...
- Changing the anti-aliasing settings affects page formatting. I find that very strange.
Back to my initial point, Java's proprietary font rendering exhibits none of these problems, so replacing it with Freetype, while unavoidable, nevertheless could be viewed as a disadvantage in some contexts.
No need Posted Oct 22, 2009 17:44 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
The it must look the same everywhere motto is another big reason SUN desktop efforts failed. No user wants one app to look the same as on some other system he's not using. He wants it to look (and behave) the same as the other apps it uses alongside it (as another example of this judgment error, see the old pre-firefox Netscape themes that were created by marketeers that thought their widgets needed to be synched with the Netscape web site look and feel). Using -insert-other-country-name- conventions in -insert-this-country-name- is not brilliant it's incredibly stupid.
Moreover looks absolutely horrible is a subjective judgement as proved time and time again when someone posts this kind of message on a list (does not matter if it's a pro-AA or anti-AA message) and discovers half the audience disagrees with his obvious statement.
Lastly when I say crap I mean actual font rendering bugs, as in respecting Unicode rules and using OpentType fatures present in the font files.
No need Posted Oct 22, 2009 18:16 UTC (Thu) by mikov (subscriber, #33179) [Link]
For sure Java's desktop failure was not caused by its font rendering. Memory consumption, slow app startup, non-native widgets, lack of desktop API integration, and so on, and so on. By virtue of its intrinsic design Java can never work well on the desktop.
Once you realize that Java is not primarily aimed at the desktop, having the same pixel-accurate result everywhere becomes very important again.
Speaking about Linux font rendering: in the case I described the qualification "absolutely horrible" is not subjective. It is a fact. Try rendering a small font on a black&white embedded LCD display. Or you can simply try disabling all anti-aliasing on your Linux desktop - you will also see something which is also objectively bad. Now go to Windows 2000 with disabled anti-aliasing and compare. These are facts.
Or try another experiment that always amazes me: change the anti-aliasing settings and observe the text in your browser being re-formatted :-) WTF? I am no font expert, but shouldn't the same text occupy the same space visually regardless of anti-aliasing settings?
Yes, I know, as Nye commented too, that some of this is probably mostly caused by the patented algorithm and lack of hinting, but it doesn't change the unfortunate end result.
About the Java font rendering bugs - I am not aware of those, but I believe you. Theoretically it would be best if those were simply fixed instead of replacing the entire implementation. (I realize that it is impossible due to licensing and other crap, etc)
No need Posted Oct 22, 2009 18:54 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
> non-native widgets
Part of the non-native feel is non-native font rendering. Also try to explain to users why an .otf fonts that works perfectly well in other apps is rejected by the java app. At last count there were ~ 400 TTF (plain TrueType or OpenType TT) files and ~ 100 OTF (OpenType CFF) files in Fedora, with OpenType TT growing fast (TrueType is years older than OpenType CFF, so it had a lot more time to create a big font pool)
> Speaking about Linux font rendering: in the case I described the
This is exactly the kind of test which people think is objective and is proved subjective time and time again
> Now go to Windows 2000
The fact is that they are different. Which one is better is 100% subjective. Windows achieves some bitmappy effect at the cost of distorting the glyphs shapes more, and people will like it or not depending if they attach more importance to the first or the second part.
> Or try another experiment that always amazes me: change the
You're not a font expert. The pixel density of a typical computer screen is not sufficient to render a vector font accurately, so the rendering algorithm needs to perform rounding on pixel lines (it is worse for CJK glyphs than for Latin, CJK computer screen rendering is horrible no matter what rendering tech you use, the pixel density is just too low. People have forgotten but before 300dpi+ laser printers it was the same mess print-side, and today's computer screens usually target ~ 100 dpi).
If you do too much rounding the glyphs lose their shape. If you don't do enough they are blurry. The AA settings let the user choose the compromise they prefer. If the computer never tried to round you'd never see the reflow you complain of. Ironically this rounding process is why you like Windows rendering so much (Microsoft uses it more heavily than Linux, and Apple less).
http://people.redhat.com/otaylor/grid-fitting/
> About the Java font rendering bugs - I am not aware of those, but I
Gratuituously reimplementing stuff that was already available in perfectly fine libs instead of working on new features no one had is another reason Java failed desktop side. Anyway the point is moot, SUN does not own all the code they use for font processing (bought the rights to some piece of crap some years ago and then forgot about it), so they can't open-source it, it will never be part of openjdk, and they'll have to replace it their side too if they don't want to pay engineers to manage two different implementations.
No need Posted Oct 22, 2009 19:48 UTC (Thu) by mikov (subscriber, #33179) [Link]
> Part of the non-native feel is non-native font rendering. Also try to
> explain to users why an .otf fonts that works perfectly well in other > apps is rejected by the java app. At last count there were ~ 400 TTF > (plain TrueType or OpenType TT) files and ~ 100 OTF (OpenType CFF) files > in Fedora, with OpenType TT growing fast (TrueType is years older than > OpenType CFF, so it had a lot more time to create a big font pool)
That is unimportant. As I said, Java is not suitable for the desktop, so any desktop-related problems are non essential. Also, I contend that the "non-native feel" of font rendering is one of the smallest problems for desktop Java. For one, Java's rendering looks very similar to Windows to my eyes, and that is where the desktop is. If everything else was fine, this would not prevent Java desktop usage.
> This is exactly the kind of test which people think is objective and is
I am sorry, but that is rubbish. I am talking of a specific engineering problem - rendering text on a small embedded B&W LCD display. The output generated by the Linux standard libraries when using True Type fonts is not acceptable. There is nothing subjective there.
>> Now go to Windows 2000
It makes no sense to press on here. Since according to you anything is by definition subjective then there is nothing to discuss. Further, if you insist on believing that non-hinted+non-antialiased _screen_ rendering in Linux is in any way superior to non-antialised _screen_ rendering in Windows (emphasis on screen, not high-DPI printer!), then there is no common ground.
However, if you try to deliver a product using that supposedly superior rendering (non-hinted, non-antialiased, small fonts), I don't expect many people would like it.
I am not talking about high quality typography here. Displaying text on a small two-color display should be a solved problem.
> You're not a font expert. The pixel density of a typical computer screen
Yes, I am familiar with the big hoopla about Apple's fonts being more blurry and the associated discussions.
I am not convinced that it is acceptable to perform reflow as a result of anti-aliasing. I am pretty sure Adobe Acrobat doesn't do that. IIRC, Apple wouldn't do that either since they are simply rendering precisely and letting anti-aliasing take care of the rest (thus the blurriness).
Also, I should note that this is not about me liking Windows rendering. It is about calling a spade a spade. Microsoft has probably invested tens of man-years into this, so it is no surprise that they would produce better results. (And licensing the patents doesn't hurt either).
I also agree that on high-DPI displays with anti-aliasing this is not an issue.
No need Posted Oct 22, 2009 20:28 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
> That is unimportant. As I said, Java is not suitable for the desktop, so
> any desktop-related problems are non essential.
Do you really want to argue there is nothing wrong with java font processing when it can not even parse the default format of most new font projects? Even giant multi-year efforts such as
Be consistent: either font processing is required, and Java is not on the level expected today, or it isn't, and comparisons of font rendering are irrelevant
> I am sorry, but that is rubbish. I am talking of a specific engineering
And many people commented on the links I posted that the Windows font rendering you think is obviously better is not acceptable either. So don't pretend it's an objective statement.
> It makes no sense to press on here. Since according to you anything is
That windows achieves "crispness" at the cost of distortion its not subjective it's a fact that can easily be checked (and has been by many people). What's subjective is the right balance between "crispness" and "no distortion". It's a compromise ie there is no 100% good solution.
> I am not talking about high quality typography here. Displaying text on
It should be but it is not. Even MS continues to invest heavily in font processing tech. So obviously they disagree with you on the "solved" part.
The only solution everyone agree would work would be to increase pixel density just like happened video-side for hd video.
> I am not convinced that it is acceptable to perform reflow as a result
The AA settings let you choose a point between the two curbs on
Of course it will cause reflow. That's obvious math. If you don't want reflow do not allow changing the settings (your font processing won't be any better quite the contrary but you'll have hidden an un-obvious, for laymen, side-effect of grid-fitting)
No need Posted Oct 23, 2009 0:48 UTC (Fri) by mikov (subscriber, #33179) [Link]
> Do you really want to argue there is nothing wrong with java font
> processing when it can not even parse the default format of most new > font projects? Even giant multi-year efforts such as > http://www.stixfonts.org/[1]
No. As I said, I believe you when you you say that there are problems. I thought we agreed that it is a moot point because it _has_ to be replaced anyway.
I am pointing out that the move to Freetype, while necessary and unavoidable, and while improving some things (as you are saying), worsens others.
I see a kind of complacency with the state of Linux font rendering, while it has clear shortcomings in some aspects.
> Be consistent: either font processing is required, and Java is not on
I am consistent. For my purposes (mostly embedded development) the current state of closed source Java font rendering works better than Freetype. Additionally, since I believe that Java has no future on the desktop, the problems you are describing are not that critical.
> And many people commented on the links I posted that the Windows font
I am not talking about random people commenting on random font rendering samples in a blog post. I don't care what they say. I am talking about delivering working products to paying customers... :-)
Windows font rendering is objectively and undeniably better at low resolutions without anti-aliasing. To deny that fact out of misguided open source loyalty is to prevent improvement in that same open source.
> That windows achieves "crispness" at the cost of distortion its not
No one is arguing with that. However you seem to assume that typographically correct rendering is always required or even preferable on a computer screen. When that screen is low DPI and low color, crispiness is all that matters.
Secondly, while there is no 100% good solution, it is enough to try reading this very page without anti-aliasing on Windows and Linux, to become convinced which solution is at least better. And I am saying this after having worked exclusively with a Linux desktop for many years - so my brain has been trained to like the Linux kind of rendering. Believe me, I eally want to like Linux better :-) But for now the path for that is to really make it better, rather than convince myself that wrong is right...
> It should be but it is not. Even MS continues to invest heavily in font
I hear you... I am typing this on a huge monitor with huge fonts and I have to say the fonts in Linux look lovely...
> The AA settings let you choose a point between the two curbs on
You are missing my point, perhaps because we are talking about two separate issues. These are conflicting goals:
I want and need both a) and b), with a way to control when I get which. The problem is in Linux out of the box I get neither! I get both ugly fonts without anti-aliasing, and I get inconsistent reflow with anti-aliasing.
No need Posted Oct 23, 2009 1:13 UTC (Fri) by mikov (subscriber, #33179) [Link]
Sorry for replying to myself, but I think this article is a worthwhile complement to my point:
http://antigrain.com/research/font_rasterization/
It show how the current state of Linux font rendering is not particularly good, and how it can be improved. Has anything been done in that direction?
No need Posted Oct 23, 2009 6:04 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
To the contrary it shows that the Linux font rendering is not as bad as people pretend, and that using the patented hinting process as windows does would be no silver bullet. It also points to ways to make freetype even better (according to the author).
Anyway the freetype devs are definitely aware of this article, if it's not implemented yet that's either because there is some legal problem, or xorg is missing the infra (typically xorg is terrible at color correction so gamma tricks are un-implementable on its current state), there is some other point missed in the article (for example, it would make desktop rendering unbearably slow with current drivers), or people just do not have the time to finish it up (I don't remember which case it is).
But anyway if you're interested in it I'm sure they would welcome patches.
And (to repeat myself) rasterization is only a very small part of font processing.
No need Posted Oct 23, 2009 6:16 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
> I am not talking about random people commenting on random font rendering
> samples in a blog post. I don't care what they say. I am talking about > delivering working products to paying customers... :-)
Typophile is not random people it's the web lair of professional font creators that need too deliver working fonts to paying customers
> No one is arguing with that. However you seem to assume that
And I contend that's a user preference, as proved by all the OMG how can I remove ugly crispy bitmap fonts post that happen every time bitmap fonts are accidentaly activated for a large user base
> I want and need both a)
BTW people seem to assume no-AA is "better", in large part because it's supposed to be faster. With modern font libs and GFX drivers, since everyone optimizes the general case users want (AA), AA rendering will be faster.
Also if you push your customers in small text at low-dpi land you'll just make non-i18n apps. Latin scripts are relatively resistant to low-dpi situations, compared to asian ones (because an ideogram for example needs higher detail density than a latin letter)
Re: Only Novell will get sued Posted Oct 16, 2009 1:30 UTC (Fri) by mikov (subscriber, #33179) [Link]
I don't see how you made the jump from Mono being vulnerable to patent threats to Java and other VM-s being vulnerable. That makes no sense.
Re: Only Novell will get sued Posted Oct 16, 2009 8:12 UTC (Fri) by AlexHudson (subscriber, #41828) [Link]
Because for the most part they work exactly the same way, and patents do not cover specific implementations - they cover the more general idea (speaking simplistically).
Thus, if Mono were to be sued, it would be either over some minor feature so inscrutable it wouldn't be a huge loss, or it would be over something so major it would inevitably cover many other programs - Java just happens to be the obvious candidate.
After all, if Java had been free earlier the Kodak suit would have been hugely depressing for free software. I'm staggered people would be willing to give that up without a fight; that would just show patent trolls that the community can be easily cowed. Sad :(
Re: Only Novell will get sued Posted Oct 16, 2009 20:43 UTC (Fri) by drag (subscriber, #31333) [Link]
Yes... Java, LLVM, Perl, Python, etc etc. All those are only slightly less
likely to violate unknown Microsoft patents as Mono itself. There is no reason why MS needs to limit patents to its own products.
So if your avoiding Mono to avoid patents your not being logical, really.
Although I would avoid using anything not covered by the EMCA standards that
Re: Only Novell will get sued Posted Oct 16, 2009 21:09 UTC (Fri) by mikov (subscriber, #33179) [Link]
No.
Considering that Java predates .NET by a significant margin and that Sun and Oracle, no to mention IBM, have their patent portfolios, it is very unlikely that Microsoft can win a patent case against Java. As a matter of fact Python and Perl also predate .NET by about 10 years.
Microsoft's patents would have to have been filed in the 1980-s, which is very unlikely.
It is actually more plausible to think that .NET violates some Sun Java patents than the other way around.
Re: Only Novell will get sued Posted Oct 17, 2009 22:03 UTC (Sat) by drag (subscriber, #31333) [Link]
And I suppose that the Java from the 1990's is the same Java that we use today, right? :)
Re: Only Novell will get sued Posted Oct 17, 2009 23:11 UTC (Sat) by nix (subscriber, #2304) [Link]
Not quite the same. It's not the in thing anymore.
(The cup has gone cold, one might say.)
Re: Only Novell will get sued Posted Oct 18, 2009 3:54 UTC (Sun) by mikov (subscriber, #33179) [Link]
Yeah, and my C compiler is not the same as the one I used in the 1990's. And your point is?
Of course Java is generally vulnerable because anybody can get sued for anything in the US. However the existence of .NET does not increase Java's vulnerability to a patent lawsuit from Microsoft specifically. So, the initial claim, that Java's patent vulnerability is similar to Mono's because they are both VMs, is invalid.
Re: Only Novell will get sued Posted Oct 19, 2009 4:57 UTC (Mon) by jamesh (guest, #1159) [Link]
The point is that changes in that there might be patents that read on code introduced to Java in that time. The existence of Java from before the patent was filed is not a defence if that old version of Java didn't infringe the patent.
And it seems pretty clear that there has been some cross-polenation of ideas between Java and C#/.Net, so the possibility exists. Of course, there it is likely that Sun would examine patents issued to direct competitors like Microsoft to see if they might cause problems.
Re: Only Novell will get sued Posted Oct 18, 2009 22:42 UTC (Sun) by cmccabe (guest, #60281) [Link]
Java is much older than .NET. It has now been released as GPLv2 and used as the foundation for a number of open-source projects including Hadoop, Android, Eclipse, etc. It's not a perfect language by any means-- but that's a whole other debate.
I think it's unfair to attack Java as "just as vulnerable as .NET." Any patents that bear on Java are almost certainly held by Oracle, who in general make a lot of money off of Linux and related technologies. They're not going to sue you for using Java because they *want* you to use Java.
On the other hand Microsoft (quite rationally) sees Linux as a threat to their stranglehold on the PC desktop. In general, Microsoft's strategy involves building interlocking pieces of infrastructure. If they can get you to use one or two pieces, they can usually force you to use the rest. Microsoft Visual Studio integrates well with Microsoft SQL Server, which works well with Microsoft .NET, which works well with... etc. Of course, the product at the end of the chain is always the same... Microsoft Windows.
Patents are just one trick-- there are a lot of other ones, like keeping key .NET libraries Windows-only. If you're doing Linux, just stay away from .NET.
C.
Re: Only Novell will get sued Posted Oct 16, 2009 15:47 UTC (Fri) by HenrikH (guest, #31152) [Link]
>I'd love to see some citation for being sued by the patent holder for being the beneficiary of patent infringement in someone else's software though.
A company called WebXchange sued three companies because the used Visual Studio: http://news.cnet.com/8301-13860_3-10099745-56.html?part=r...
I also recall several companies getting sued due to patents in MS SQL Server a few years ago.
Re: Only Novell will get sued Posted Oct 16, 2009 20:50 UTC (Fri) by AlexHudson (subscriber, #41828) [Link]
Right, but it's not as simple as that unless you get into the actual specifics of the action.
E.g., "WebXchange alleges that FedEx violates three of its patents in an online system that lets people send print jobs to Kinko's stores." - http://www.techworld.com.au/article/267716/microsoft_file...
Quite possibly FedEx built their system out of standard components that come with Visual Studio. I'm not sure that counts as "being sued for relying on someone else's infringement".
Monomania (Tux Deluxe) Posted Oct 16, 2009 6:09 UTC (Fri) by sitaram (subscriber, #5959) [Link]
I guess I have a new (or yet another!) hero...
I just hope Mandriva doesn't get these "install mono by default" ideas, but fortunately a "no bloat" objective (as espoused by LXDE and such) is sufficient garlic, so there's always be those distros to fall back on.
|
|||||||||||||