Because no other part of Unix depends on file extensions to decide what to do. The system already provides a fast test to see if a file is a directory, that can be used to make this decision.
Users should be able to to rename the file to anything and have it work. However this is a good argument for calling the executable "main" or some other fixed name, rather than the name of the program. The only reason I suggested the name of the program is so that "ps" will work without kernel changes. Using a fixed name like this will also allow you to use.app if that is your preference.
Also.app is bad idea because it requires a user-friendly interface to hide the filename extension.
I may have typed it wrong, but the loop is supposed to exit when the readlink fails because the file is not a link.
I believe the relative path part is not required on Linux. It is there because this same code was used on Unix systems that don't have/proc, where it searches the path for the known name instead of starting at/proc/self/exe. This is necessary there because people often put relative linkes into those paths.
Detecting if something is modified is completely different than preventing it from being modified.
Relying on prevention of modification is extremely dangerous and perhaps worse than doing nothing at all. This is because you have provided the person intent on modifying the data with a foolproof test to see if they succeeded (ie if it copies, they have broken it!)
It is also pretty much a given that DRM cannot work with an open standard (though I am unclear if this can be proven). However MD5 style checksums obvoulsly do work with an open standard. Absolutely for any legal stuff we want to base it on an open standard.
KDE merges the menu entries stored in some central files (under/etc?) with the ones in your home directory. So modifying the central entries should be able to add an item to everybody's start menu. I assumme the same is true for Gnome.
It would help if their documentation provided clear examples, with actual file names of where this stuff is stored, however. I was unable to locate it quickly enough to provide a better answer to your question.
This is exactly what should be done, but people here are too brainwashed to admit that perhaps some features of Posix should be changed.
It is possible to fake this, we do it with our commercial Linux software, and it is obvious that other commercial software does this:
*All* files for your software are dumped into a single directory, so installation and removal is trivial (this is similar to OS/X App directories). In that directory is a single "wrapper" executable, usually with the name of your program, and only dependent on glibc. The main thing this program does is read/proc/self/exe and use it to setenv LD_LIBRARY_PATH, and locate the actual executable. It then exec's the actual executable. In our case the wrapper also makes sure argv[0] is a clean full path name so the actual executable can use it to locate data files and plugins, you could also put this function in the main program if you wanted.
We then install Gnome and KDE shortcuts on their start menus directly pointing at the full pathname of the executable. Anybody who wants to run it from a shell has to type the full path or symbolically link it themselves into a directory on their path. Deleting our software leaves these start menu items and any symbolic links pointing at nothing, which as far as I can tell is not a real problem.
Intelligent users can easily peek into our directories and see that we ship libtcl and some others in an attempt to hide system differences. They can rename or remove these to better integrate the software into their system. But at least it works, first time, for any users.
I would like to see Linux altered to handle this cleanly, by adding direct support for "app directories". Unlike OS/X, I think they should be named with no extension. The rules are simple: if the user tries to run "foo" and it is a directory, it tries to run "foo/foo" after first adding foo to the LD_LIBRARY_PATH and after fixing up argv[0] to be the full expanded path to foo, and possibly other fixes for stupid Posix rules. This would get rid of 99% of the "install" headaches.
This code will find the full path name to the current executable:
buffer[1024];
strcpy(buffer, "/proc/self/exe");
for (;;) {
char buf2[1024];
int n = readlink(buffer, buf2, 1023);
if (n <= 0) break;
buf2[n] = 0;
if (buf2[0]=='/') {
strcpy(buffer, buf2);
} else {// Handle a relative link:// copy up through the last slash:
char* p = buffer;
char* a = p;
const char* b = program_name;
while (*b) if ((*a++ = *b++)=='/') p = a;// Skip leading./:
b = buf2; while (b[0]=='.' && b[1]=='/') b += 2;// now put the filename there to get a relative filename:// This may overflow the buffer!
strcpy(p, b);
}
}// Full path to the current executable is now in buffer
(obviously cleaner code that cannot overflow buffers should be written and stuck in a function, but it is not impossible).
The script "runs" because bash was told to run it. It does not check the executable bit.
Try this:
% cat > foo echo "The program was run" ^D % ls -l foo -rw-r--r--... (no x) % bash foo The program was run % bash foo The program was run
In the second example bash does not even know the name of the file so it cannot check the executable bit even if it wanted to!
In fact at a low level the exec() call does not bother checking the executable bit. It's purpose is to be used by the shell to decide if it should run the program or not. And the executable bit is not a security invention, it was made for early Unix systems with limited memory, where a shell would want to cache all the commands it could run so it could find them quickly without searching the path. The executable bit allowed the shell to remember only the programs and not have to store every file it found on the path. This is obsolete nowadays due not only to much more memory but due to modern file system layout where directories tend to have only executables in them.
Apparently the morons are ruling here at Slashdot. It used to be amusing when some Microsoft fanboy said something factually incorrect, but now everybody does and it is just sad.
You seem to be confused about what part of Linux is being ported.
The equivalent of your idea is for Microsoft's phone OS to be able to run an unmodified version of Microsoft Word. Though perhaps interesting to a few people, it should be pretty obvious that this is unnecessary and probably undesirable for a phone, and is not what Micorsoft is going to do. This does not mean that they cannot reuse great amounts of code they have written for Windows.
In the same way, a Linux phone that can run X might be interesting to a few people, but certainly not what everybody wants or needs. This does not mean that a great deal of Linux cannot be reused for this phone.
And DPIs aren't there to annoy you, some people really do work on 300dpi monitors with regularity.
If I am forced to figure out the DPI to draw a 1" square, then having the fonts in "points" serves NO purpose. So unless the API for that 300-dpi monitor allows scaling, and can easily be set so that a unit is 1/72 of an inch, then no I do not want "points" I do not want points even if it is a million dots per inch. I want the same units that all other graphics are drawn in. How many times do I have to say this?
Even if it does allow scaling, I would copy Cairo which has decided that the nearest integer multiple of 1/96 should be used. This is needed so that antialiasing does not show up unexpectedly in your graphics. Fonts should definately be specified in current units, otherwise with this even more complex rules for default transform I have to do even more annoying work to get a font to match my other graphics!
I would never, ever, accept an interface that took "points" unless the normal interface for drawing lines accepted units that are 1/72 of an inch (that is not impossible. With sufficently advanced anti-aliasing algorithims you may eliminate the need to match any graphics to pixel boundaries). However even the most advanced algorithims will not excuse an interface where I have to keep track of two different CTM's just to match the size of some of my graphics to others.
So, what shape should a "40 pixel Bodoni font" have?
It should have the shape you would have chosen for a 40*72/DPI point font in your scheme.
Should the shape of the font you get change with the resolution of your screen?
YES!!!!! As long as the general size in units does not change. I mean I could substitue a different font for "Bodoni" and the widths and letterforms might all change, but I certainly would never expect the vertical size to change. Besides in the "complex" interface where it takes both pixel and point sizes this can easily be avoided.
IMHO the answers to these questions are glaringly obvious and totally trivial to implement. I do not understand why you think this is somehow difficult.
I just tried that (had to fill out the "wizard") and it is obvious that ctrl+x and ctrl+v are intended to work, so that does not count. Your claim is that programs are "inconsistent", not that they have bugs. Please try again and find a program where cut & paste do not exist or exist on a key that is different that ctrl+x or ctrl+v. Or (probably easier) find a recent program where they mess with the middle-mouse drag & drop selection.
Certainly "pan" is messed up in ways I have not seen before. Selecting text often turns off the selection immediately, and usually does not set the middle-mouse-paste buffer, so they broke the classic X drag & drop selection as well as cut & paste. Ctrl+x and ctrl+v work inside the program, in the same field and between fields, but do not seem to affect anything visible from outside at all (ie it does not have the usual bug in old programs where it messes with the drag & drop middle-mouse selection). This does indicate to me a deliberate intention to make ctrl+x and ctrl+v work, even if the programmers are idiots.
Monopoly by definition does not include the government, no matter how evil and controlling that government is. Though I don't always agree with them, most Libertarians are quite intelligent and logical, and you are insulting them with such stupid arguments.
If the evil government said everybody *must* purchase Microsoft, then Microsoft would still be the monopoly, not the government. The government would be a bad government.
PS: Microsoft certainly is a monopoly. It is physically impossible to do many things that are required in life (such as work at many jobs) without purchasing a product from Microsoft (ie you must have it on your home computer).
PPS: A lot of the power of the monopoly Microsoft and of Disney (who really are not a monopoly) are due to anti-libertarian laws such as copyright and patents and protectionism. You should be finding arguments on how these laws are helping unscrupulous and greedy people to get more power than they should be able to have under a "free" system.
I just tried both Emacs and VI on Windows, and guess what: ctrl+x and ctrl+v DO NOT WORK THERE EITHER! Amazing, this must be proof that Windows sucks.
I challenge you to find a single "modern" X program (ie something written since KDE or Gnome were introduced) that does not use ctrl+x and ctrl+v for cut and paste.
So, you have to specify the point size because that determines the shape of the font. And since the point size implies a default pixel size through the known resolution, people figure they might as well make that "natural" size the default rendering size, because that's often the size people want anyway.
Yes I am aware that that is the logic that was used to arrive at the current situation.
There would be nothing wrong with an interface that took the font size in pixels or in current units as the "simplified" interface. You could still render the font correctly for it's size by the simple step of converting the pixel size to points to select the rendering algorithm. For instance if the complicated call is "setfont(pixels, points)" the simple call is "setfont(pixels, pixels*72/DPI)".
I really don't care how logical or anything else selecting fonts by points seems to be. They are graphic elements and they should be measured the same. Ask any user anywhere, such as all those Windows users that insist that changing the screen resolution is important, and see if any of them would be happy if this caused all the fonts to re-render. I'm afraid you are going to find the answer is no. I am completely pissed off at KDE for obeying the DPI, since the dpi comes up with random values each time I reboot the machine (switching between 75 and 100). What should be a minor XFree86 bug is turned into a complete disasterous headache, despite the fact that KDE is working "perfectly" according to your definition. Fixing this results in it printing fonts the wrong size, too. Also Microsoft has forced their DPI setting to 96 at all times, since they (probably due to user testing) have realized this is a misfeature and have decided to disable it as best they can.
I have seen arguments that the "Instant Runoff Voting" method used in Austraila is mathmatically flawed and this may be a result. Straight "approval voting" where you don't rank anybody is apparently better.
A whole lot of information is here. Note that the site appears to have a slight Libertarian bias, but I don't think this detracts from the mathematical accuracy of their analysis.
I think we have established now that a single TrueType fonts can have different shapes depending on the point size it is rendered at, so that simply scaling one to match the size of the other will not give you the same thing. That's all I'm saying.
Yes, but we have also established that asking for "bold" or "italic" should change the letter forms, too. However the interface you are suggesting is the same as if asking for "bold" always returned a font that was 1.2 times taller. Do you really think that makes it easier to mix bold and normal text? No I submit that it makes it MUCH harder!
Your pseudo-code implies that you think asking for an N-point font returns a font that is N UNITS tall. This is because you clearly state that you think that a scale of desired_size/N put into the CTM would produce the desired font size. Unfortunatly, and this is where my argument is, all the interfaces I have seen return a font that is N*DPI/72 pixels tall. Thus to get a predictable size I must look up the DPI and do a division. Now you could try to argue that this makes sense, but if it does, why don't I have to do it for every other graphics call?
This has nothing to do with a PostScript like interface where it is possible to set the CTM so the units are 1/72 inch. In that case, fonts are selected in "points", but so are all the other graphics!!!
My complaint is that in all current systems for screen graphics, the font is selected in a mysterious unit that is different than every other graphic. This is a stupid, brain-dead method and no amount of typographic history or buzzwords will change that fact!
I think there is a flaw in the system. In effect if you plot the platforms of Gore and Bush on the entire political opinion spectrum, you would get something like this:
LEFT------GB------RIGHT
Most people when they think about politics expect it to maybe be more like this (showing a case where Bush would win):
LEFT---G----B-----RIGHT
The actual result is the same as very simple economic theories such as "where to put your resturant along the road to compete with other resturants". They all end up clustered in the exact center of the population on the road, which is not the idea distribution for the users of the resturants.
If Gore moved slightly more liberal, Bush would win. If Bush went slightly more conservative Gore would win. They end up in the exact middle and modern candidates have millions of dollars in analysists to find the real exact middle. In fact the main parties have changes which one is left/right a couple times during the history of the United States due to them trying so hard to be exactly in the middle that they went past each other.
Not that I have any idea what the solution is. Possibly approval voting would fix this (where you can vote for more than one candidate).
Actually several recounts showed Gore winning. The really foolish thing the Dems did was insist on certain precients being recounted and that count ended up showing Bush winning anyway, if they had selected a different set of precients or *all* precients they could have shown Gore winning. That pretty much made them look really stupid and lost their argument for anybody (like me) who didn't really care (personally I think something is wrong with our system that the two candidates can so exactly center themselves that the vote is divided so perfectly).
He IS being sarcastic. If this was a Microsoft bug and they said "It's just a crash" it surely would be quoted exactly the same way, because it is a silly statement. Let's see:
*no comment* writes "If you are IPv6 on WinXP, it might be time to upgrade to Linux (just kidding). There is, however, a way to crash WinXP with a couple of simple IPv6 commands. Georgi Guninski, found the problem. To quote Bill Gates, 'it is just a crash.'" It is unknown if the bug could be used to execute arbitrary code, but it does require patching a Linux kernel (or rolling your own network stack) to exploit.
Okay, now that the wording has been changed to Microsoft, doesn't it suddenly look like a typical rabid-anti-Microsoft Slashdot article? You are so blinded by the belief that everything is anti-Microsoft that you cannot even see people being sarcastic about anything not Microsoft!
Yes I read it. It talks almost entirely about changing letter shapes for rasterization, though it does mention the type of scaling you are talking about, calling it "Optical scaling".
I'm confused why you think your pseudocode is doing what I want. I want the argument to be "physsize_in_UNITS", where "units" are the same dimension that I would send to the path contstruction calls or to fill a rectangle.
Your code as written would work, if and only if getfont(name,n) returned a font that is exactly n units tall. Then scaling by physsize_in_units/n would result in the correctly-sized font. However making a font n units tall means IT IS NOT MEASURED IN POINTS!!!
If in fact your getfont() returns an image scaled to be a certain number of points tall, we are forced to scale by the desired size times the inverse transformation of that number of points to the current space. This is nowhere near as simple as you seem to think. Even if you ignore rotations, skew, and different x/y scale, it is going to be:
I'd like to know what you think rotated, skewed, or 3-D current transforms should do when you specify fonts in "points".
Please let me repeat: I fully understand the desire to change the letterforms based on a "point size". This has nothing to do with what I want. Let me show you some pseudo-code where in my scheme you can select fonts by "points" in an entirely unambiguous way:
I've said before that if someone discovered Linux was in use in a prison system somewhere, the/. headline for that would read: "Windows Still Used To Violate Civil Rights" or something equally idiotic.
I suspect you meant to type that if Windows was used in a prison system, the headline would be that. While if Linux was used the headline would be something like "Linux used to rehabilitate prisoners".
If you are going to insult Slashdot, try typing a little more carefully so you don't look like an idiot.
On X, yes, there are two fields for the "point size" and "pixel size" in a font. However any attempt to specify them seperately results in a non-existent font on traditional X servers. On ones using FreeType it appears the pixel size is ignored. The only way to get a specific pixel size is to put a "*" into the point size.
On Win32 GDI32 there is only a single number passed to the font selector. If positive it is point size and if negative it is the pixel size. It is not possible to specify both at once.
In Xft/Fontselect there is a way to specify both (the call takes a list of attribute name/value pairs), but some trivial tests show that the last one specified takes precedence. The first one you specify is ignored.
Scalable systems like PostScript and PDF seem to get it right. They let you specify the font size in "current units". Yes those current units can change size, but the font is specified in them! You know what size you are getting without having to query about the DPI. I am unaware of any implementation actually changing the glyphs based on the resulting physical size of the font, though this is certainly allowed.
If modern Windows GDI allows scaling, the definately should NOT specify point size, as the size is now meaningless. It is either scaled by the current transformation and then by the "DPI" to get the font, or it is ignored which means you must do an inverse transformation and DPI multiplication to figure out how big the font is.
All non-linear-scaling I have ever seen has been pixel-based. On modern anti-aliased font renderers it is mostly concerned with changing the widths of characters to integers so that a row of repeating characters looks even. Again this is much better specified in pixels.
I agree that a perception-based font renderer that changes the shapes based on physical size is a good idea, but none of the systems do this. I would agree with you if you could point out a system where the following is true:
1. You can specify a font size in the same units that you use to draw everything else. On most systems this means in pixels, on scalable systems this means in "current units". This unit can be "points" if and only if other graphics are also measured in "points". The "size" can be a single number or a 2x2 matrix or even more complicated transformation.
2. The result of setting a font size to N units tall is that an "em space" is N units in size. Another way of saying this is if the lines of text are spaced N units apart they look reasonable (though most people would feel they are tightly packed) and they look approximatly equally packed together no matter what N value is chosen.
3. There is a way to specify a "point size" that is used to control the rendering. This can be specified in points or any other physical unit like angstroms. Probably this is given to the same call, but it could be specified in a seperate call. Like the size, this can be a 2x2 matrix or even more complex information. This must not change the "em space" size. It can change the appearance and width of the glyphs in any way it wants, however.
It "relies" on the fact that Outlook can be fooled into hiding the extensions on files. The arrived document is disguised to not be an.exe.
I agree that a lot of this is social engineering, and lots of people clicked on it in other email readers or in Outlook with the extensions showing. However the virus purposely included code specifically designed to use a misfeature in Outlook if it could, so saying no Microsoft vulnerability is involved is false. I guess it does not "rely" on the vulnerability, but Microsoft is not blameless here.
Slashdot Mirror
Because no other part of Unix depends on file extensions to decide what to do. The system already provides a fast test to see if a file is a directory, that can be used to make this decision.
.app if that is your preference.
.app is bad idea because it requires a user-friendly interface to hide the filename extension.
Users should be able to to rename the file to anything and have it work. However this is a good argument for calling the executable "main" or some other fixed name, rather than the name of the program. The only reason I suggested the name of the program is so that "ps" will work without kernel changes. Using a fixed name like this will also allow you to use
Also
I may have typed it wrong, but the loop is supposed to exit when the readlink fails because the file is not a link.
/proc, where it searches the path for the known name instead of starting at /proc/self/exe. This is necessary there because people often put relative linkes into those paths.
I believe the relative path part is not required on Linux. It is there because this same code was used on Unix systems that don't have
This has absolutely nothing to do with DRM.
Detecting if something is modified is completely different than preventing it from being modified.
Relying on prevention of modification is extremely dangerous and perhaps worse than doing nothing at all. This is because you have provided the person intent on modifying the data with a foolproof test to see if they succeeded (ie if it copies, they have broken it!)
It is also pretty much a given that DRM cannot work with an open standard (though I am unclear if this can be proven). However MD5 style checksums obvoulsly do work with an open standard. Absolutely for any legal stuff we want to base it on an open standard.
KDE merges the menu entries stored in some central files (under /etc?) with the ones in your home directory. So modifying the central entries should be able to add an item to everybody's start menu. I assumme the same is true for Gnome.
It would help if their documentation provided clear examples, with actual file names of where this stuff is stored, however. I was unable to locate it quickly enough to provide a better answer to your question.
This is exactly what should be done, but people here are too brainwashed to admit that perhaps some features of Posix should be changed.
/proc/self/exe and use it to setenv LD_LIBRARY_PATH, and locate the actual executable. It then exec's the actual executable. In our case the wrapper also makes sure argv[0] is a clean full path name so the actual executable can use it to locate data files and plugins, you could also put this function in the main program if you wanted.
It is possible to fake this, we do it with our commercial Linux software, and it is obvious that other commercial software does this:
*All* files for your software are dumped into a single directory, so installation and removal is trivial (this is similar to OS/X App directories). In that directory is a single "wrapper" executable, usually with the name of your program, and only dependent on glibc. The main thing this program does is read
We then install Gnome and KDE shortcuts on their start menus directly pointing at the full pathname of the executable. Anybody who wants to run it from a shell has to type the full path or symbolically link it themselves into a directory on their path. Deleting our software leaves these start menu items and any symbolic links pointing at nothing, which as far as I can tell is not a real problem.
Intelligent users can easily peek into our directories and see that we ship libtcl and some others in an attempt to hide system differences. They can rename or remove these to better integrate the software into their system. But at least it works, first time, for any users.
I would like to see Linux altered to handle this cleanly, by adding direct support for "app directories". Unlike OS/X, I think they should be named with no extension. The rules are simple: if the user tries to run "foo" and it is a directory, it tries to run "foo/foo" after first adding foo to the LD_LIBRARY_PATH and after fixing up argv[0] to be the full expanded path to foo, and possibly other fixes for stupid Posix rules. This would get rid of 99% of the "install" headaches.
This code will find the full path name to the current executable:
// Handle a relative link: // copy up through the last slash: // Skip leading ./: // now put the filename there to get a relative filename: // This may overflow the buffer! // Full path to the current executable is now in buffer
buffer[1024];
strcpy(buffer, "/proc/self/exe");
for (;;) {
char buf2[1024];
int n = readlink(buffer, buf2, 1023);
if (n <= 0) break;
buf2[n] = 0;
if (buf2[0]=='/') {
strcpy(buffer, buf2);
} else {
char* p = buffer;
char* a = p;
const char* b = program_name;
while (*b) if ((*a++ = *b++)=='/') p = a;
b = buf2; while (b[0]=='.' && b[1]=='/') b += 2;
strcpy(p, b);
}
}
(obviously cleaner code that cannot overflow buffers should be written and stuck in a function, but it is not impossible).
The second example was supposed to read "bash < foo". Should have pushed preview, but I guess I am also a Slashdot moron...
The script "runs" because bash was told to run it. It does not check the executable bit.
... (no x)
Try this:
% cat > foo
echo "The program was run"
^D
% ls -l foo
-rw-r--r--
% bash foo
The program was run
% bash foo
The program was run
In the second example bash does not even know the name of the file so it cannot check the executable bit even if it wanted to!
In fact at a low level the exec() call does not bother checking the executable bit. It's purpose is to be used by the shell to decide if it should run the program or not. And the executable bit is not a security invention, it was made for early Unix systems with limited memory, where a shell would want to cache all the commands it could run so it could find them quickly without searching the path. The executable bit allowed the shell to remember only the programs and not have to store every file it found on the path. This is obsolete nowadays due not only to much more memory but due to modern file system layout where directories tend to have only executables in them.
Apparently the morons are ruling here at Slashdot. It used to be amusing when some Microsoft fanboy said something factually incorrect, but now everybody does and it is just sad.
You seem to be confused about what part of Linux is being ported.
The equivalent of your idea is for Microsoft's phone OS to be able to run an unmodified version of Microsoft Word. Though perhaps interesting to a few people, it should be pretty obvious that this is unnecessary and probably undesirable for a phone, and is not what Micorsoft is going to do. This does not mean that they cannot reuse great amounts of code they have written for Windows.
In the same way, a Linux phone that can run X might be interesting to a few people, but certainly not what everybody wants or needs. This does not mean that a great deal of Linux cannot be reused for this phone.
Of course it's so obvious that the GPL is the problem! That's why every single machine in the world runs BSD!
And DPIs aren't there to annoy you, some people really do work on 300dpi monitors with regularity.
If I am forced to figure out the DPI to draw a 1" square, then having the fonts in "points" serves NO purpose. So unless the API for that 300-dpi monitor allows scaling, and can easily be set so that a unit is 1/72 of an inch, then no I do not want "points" I do not want points even if it is a million dots per inch. I want the same units that all other graphics are drawn in. How many times do I have to say this?
Even if it does allow scaling, I would copy Cairo which has decided that the nearest integer multiple of 1/96 should be used. This is needed so that antialiasing does not show up unexpectedly in your graphics. Fonts should definately be specified in current units, otherwise with this even more complex rules for default transform I have to do even more annoying work to get a font to match my other graphics!
I would never, ever, accept an interface that took "points" unless the normal interface for drawing lines accepted units that are 1/72 of an inch (that is not impossible. With sufficently advanced anti-aliasing algorithims you may eliminate the need to match any graphics to pixel boundaries). However even the most advanced algorithims will not excuse an interface where I have to keep track of two different CTM's just to match the size of some of my graphics to others.
So, what shape should a "40 pixel Bodoni font" have?
It should have the shape you would have chosen for a 40*72/DPI point font in your scheme.
Should the shape of the font you get change with the resolution of your screen?
YES!!!!! As long as the general size in units does not change. I mean I could substitue a different font for "Bodoni" and the widths and letterforms might all change, but I certainly would never expect the vertical size to change. Besides in the "complex" interface where it takes both pixel and point sizes this can easily be avoided.
IMHO the answers to these questions are glaringly obvious and totally trivial to implement. I do not understand why you think this is somehow difficult.
I just tried that (had to fill out the "wizard") and it is obvious that ctrl+x and ctrl+v are intended to work, so that does not count. Your claim is that programs are "inconsistent", not that they have bugs. Please try again and find a program where cut & paste do not exist or exist on a key that is different that ctrl+x or ctrl+v. Or (probably easier) find a recent program where they mess with the middle-mouse drag & drop selection.
Certainly "pan" is messed up in ways I have not seen before. Selecting text often turns off the selection immediately, and usually does not set the middle-mouse-paste buffer, so they broke the classic X drag & drop selection as well as cut & paste. Ctrl+x and ctrl+v work inside the program, in the same field and between fields, but do not seem to affect anything visible from outside at all (ie it does not have the usual bug in old programs where it messes with the drag & drop middle-mouse selection). This does indicate to me a deliberate intention to make ctrl+x and ctrl+v work, even if the programmers are idiots.
Monopoly by definition does not include the government, no matter how evil and controlling that government is. Though I don't always agree with them, most Libertarians are quite intelligent and logical, and you are insulting them with such stupid arguments.
If the evil government said everybody *must* purchase Microsoft, then Microsoft would still be the monopoly, not the government. The government would be a bad government.
PS: Microsoft certainly is a monopoly. It is physically impossible to do many things that are required in life (such as work at many jobs) without purchasing a product from Microsoft (ie you must have it on your home computer).
PPS: A lot of the power of the monopoly Microsoft and of Disney (who really are not a monopoly) are due to anti-libertarian laws such as copyright and patents and protectionism. You should be finding arguments on how these laws are helping unscrupulous and greedy people to get more power than they should be able to have under a "free" system.
I just tried both Emacs and VI on Windows, and guess what: ctrl+x and ctrl+v DO NOT WORK THERE EITHER! Amazing, this must be proof that Windows sucks.
I challenge you to find a single "modern" X program (ie something written since KDE or Gnome were introduced) that does not use ctrl+x and ctrl+v for cut and paste.
So, you have to specify the point size because that determines the shape of the font. And since the point size implies a default pixel size through the known resolution, people figure they might as well make that "natural" size the default rendering size, because that's often the size people want anyway.
Yes I am aware that that is the logic that was used to arrive at the current situation.
There would be nothing wrong with an interface that took the font size in pixels or in current units as the "simplified" interface. You could still render the font correctly for it's size by the simple step of converting the pixel size to points to select the rendering algorithm. For instance if the complicated call is "setfont(pixels, points)" the simple call is "setfont(pixels, pixels*72/DPI)".
I really don't care how logical or anything else selecting fonts by points seems to be. They are graphic elements and they should be measured the same. Ask any user anywhere, such as all those Windows users that insist that changing the screen resolution is important, and see if any of them would be happy if this caused all the fonts to re-render. I'm afraid you are going to find the answer is no. I am completely pissed off at KDE for obeying the DPI, since the dpi comes up with random values each time I reboot the machine (switching between 75 and 100). What should be a minor XFree86 bug is turned into a complete disasterous headache, despite the fact that KDE is working "perfectly" according to your definition. Fixing this results in it printing fonts the wrong size, too. Also Microsoft has forced their DPI setting to 96 at all times, since they (probably due to user testing) have realized this is a misfeature and have decided to disable it as best they can.
I have seen arguments that the "Instant Runoff Voting" method used in Austraila is mathmatically flawed and this may be a result. Straight "approval voting" where you don't rank anybody is apparently better.
A whole lot of information is here. Note that the site appears to have a slight Libertarian bias, but I don't think this detracts from the mathematical accuracy of their analysis.
I think we have established now that a single TrueType fonts can have different shapes depending on the point size it is rendered at, so that simply scaling one to match the size of the other will not give you the same thing. That's all I'm saying.
Yes, but we have also established that asking for "bold" or "italic" should change the letter forms, too. However the interface you are suggesting is the same as if asking for "bold" always returned a font that was 1.2 times taller. Do you really think that makes it easier to mix bold and normal text? No I submit that it makes it MUCH harder!
Your pseudo-code implies that you think asking for an N-point font returns a font that is N UNITS tall. This is because you clearly state that you think that a scale of desired_size/N put into the CTM would produce the desired font size. Unfortunatly, and this is where my argument is, all the interfaces I have seen return a font that is N*DPI/72 pixels tall. Thus to get a predictable size I must look up the DPI and do a division. Now you could try to argue that this makes sense, but if it does, why don't I have to do it for every other graphics call?
This has nothing to do with a PostScript like interface where it is possible to set the CTM so the units are 1/72 inch. In that case, fonts are selected in "points", but so are all the other graphics!!!
My complaint is that in all current systems for screen graphics, the font is selected in a mysterious unit that is different than every other graphic. This is a stupid, brain-dead method and no amount of typographic history or buzzwords will change that fact!
I think there is a flaw in the system. In effect if you plot the platforms of Gore and Bush on the entire political opinion spectrum, you would get something like this:
LEFT------GB------RIGHT
Most people when they think about politics expect it to maybe be more like this (showing a case where Bush would win):
LEFT---G----B-----RIGHT
The actual result is the same as very simple economic theories such as "where to put your resturant along the road to compete with other resturants". They all end up clustered in the exact center of the population on the road, which is not the idea distribution for the users of the resturants.
If Gore moved slightly more liberal, Bush would win. If Bush went slightly more conservative Gore would win. They end up in the exact middle and modern candidates have millions of dollars in analysists to find the real exact middle. In fact the main parties have changes which one is left/right a couple times during the history of the United States due to them trying so hard to be exactly in the middle that they went past each other.
Not that I have any idea what the solution is. Possibly approval voting would fix this (where you can vote for more than one candidate).
Actually several recounts showed Gore winning. The really foolish thing the Dems did was insist on certain precients being recounted and that count ended up showing Bush winning anyway, if they had selected a different set of precients or *all* precients they could have shown Gore winning. That pretty much made them look really stupid and lost their argument for anybody (like me) who didn't really care (personally I think something is wrong with our system that the two candidates can so exactly center themselves that the vote is divided so perfectly).
He IS being sarcastic. If this was a Microsoft bug and they said "It's just a crash" it surely would be quoted exactly the same way, because it is a silly statement. Let's see:
*no comment* writes "If you are IPv6 on WinXP, it might be time to upgrade to Linux (just kidding). There is, however, a way to crash WinXP with a couple of simple IPv6 commands. Georgi Guninski, found the problem. To quote Bill Gates, 'it is just a crash.'" It is unknown if the bug could be used to execute arbitrary code, but it does require patching a Linux kernel (or rolling your own network stack) to exploit.
Okay, now that the wording has been changed to Microsoft, doesn't it suddenly look like a typical rabid-anti-Microsoft Slashdot article? You are so blinded by the belief that everything is anti-Microsoft that you cannot even see people being sarcastic about anything not Microsoft!
I can only say it again: read the Microsoft page.
t s*DPI/72)
Yes I read it. It talks almost entirely about changing letter shapes for rasterization, though it does mention the type of scaling you are talking about, calling it "Optical scaling".
I'm confused why you think your pseudocode is doing what I want. I want the argument to be "physsize_in_UNITS", where "units" are the same dimension that I would send to the path contstruction calls or to fill a rectangle.
Your code as written would work, if and only if getfont(name,n) returned a font that is exactly n units tall. Then scaling by physsize_in_units/n would result in the correctly-sized font. However making a font n units tall means IT IS NOT MEASURED IN POINTS!!!
If in fact your getfont() returns an image scaled to be a certain number of points tall, we are forced to scale by the desired size times the inverse transformation of that number of points to the current space. This is nowhere near as simple as you seem to think. Even if you ignore rotations, skew, and different x/y scale, it is going to be:
scale = physsize_in_units*current_scale/(fontsize_in_poin
I'd like to know what you think rotated, skewed, or 3-D current transforms should do when you specify fonts in "points".
Please let me repeat: I fully understand the desire to change the letterforms based on a "point size". This has nothing to do with what I want. Let me show you some pseudo-code where in my scheme you can select fonts by "points" in an entirely unambiguous way:
scale(DPI/72, DPI/72);
pickfont(actual_size=n, render_as_though_point_size=n);
DONE!!!!
I've said before that if someone discovered Linux was in use in a prison system somewhere, the /. headline for that would read: "Windows Still Used To Violate Civil Rights" or something equally idiotic.
I suspect you meant to type that if Windows was used in a prison system, the headline would be that. While if Linux was used the headline would be something like "Linux used to rehabilitate prisoners".
If you are going to insult Slashdot, try typing a little more carefully so you don't look like an idiot.
You obviously have not used these interfaces.
On X, yes, there are two fields for the "point size" and "pixel size" in a font. However any attempt to specify them seperately results in a non-existent font on traditional X servers. On ones using FreeType it appears the pixel size is ignored. The only way to get a specific pixel size is to put a "*" into the point size.
On Win32 GDI32 there is only a single number passed to the font selector. If positive it is point size and if negative it is the pixel size. It is not possible to specify both at once.
In Xft/Fontselect there is a way to specify both (the call takes a list of attribute name/value pairs), but some trivial tests show that the last one specified takes precedence. The first one you specify is ignored.
Scalable systems like PostScript and PDF seem to get it right. They let you specify the font size in "current units". Yes those current units can change size, but the font is specified in them! You know what size you are getting without having to query about the DPI. I am unaware of any implementation actually changing the glyphs based on the resulting physical size of the font, though this is certainly allowed.
If modern Windows GDI allows scaling, the definately should NOT specify point size, as the size is now meaningless. It is either scaled by the current transformation and then by the "DPI" to get the font, or it is ignored which means you must do an inverse transformation and DPI multiplication to figure out how big the font is.
All non-linear-scaling I have ever seen has been pixel-based. On modern anti-aliased font renderers it is mostly concerned with changing the widths of characters to integers so that a row of repeating characters looks even. Again this is much better specified in pixels.
I agree that a perception-based font renderer that changes the shapes based on physical size is a good idea, but none of the systems do this. I would agree with you if you could point out a system where the following is true:
1. You can specify a font size in the same units that you use to draw everything else. On most systems this means in pixels, on scalable systems this means in "current units". This unit can be "points" if and only if other graphics are also measured in "points". The "size" can be a single number or a 2x2 matrix or even more complicated transformation.
2. The result of setting a font size to N units tall is that an "em space" is N units in size. Another way of saying this is if the lines of text are spaced N units apart they look reasonable (though most people would feel they are tightly packed) and they look approximatly equally packed together no matter what N value is chosen.
3. There is a way to specify a "point size" that is used to control the rendering. This can be specified in points or any other physical unit like angstroms. Probably this is given to the same call, but it could be specified in a seperate call. Like the size, this can be a 2x2 matrix or even more complex information. This must not change the "em space" size. It can change the appearance and width of the glyphs in any way it wants, however.
It "relies" on the fact that Outlook can be fooled into hiding the extensions on files. The arrived document is disguised to not be an .exe.
I agree that a lot of this is social engineering, and lots of people clicked on it in other email readers or in Outlook with the extensions showing. However the virus purposely included code specifically designed to use a misfeature in Outlook if it could, so saying no Microsoft vulnerability is involved is false. I guess it does not "rely" on the vulnerability, but Microsoft is not blameless here.