CVS: main/DOCS/man/en mplayer.1,1.1049,1.1050
CVS change done by Diego Biurrun CVS Update of /cvsroot/mplayer/main/DOCS/man/en In directory mail:/var2/tmp/cvs-serv16911/DOCS/man/en Modified Files: mplayer.1 Log Message: Formatting and wording fixes. Index: mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.1049 retrieving revision 1.1050 diff -u -r1.1049 -r1.1050 --- mplayer.1 26 Jul 2005 10:25:00 -0000 1.1049 +++ mplayer.1 26 Jul 2005 10:41:59 -0000 1.1050 @@ -2653,14 +2653,16 @@ . .TP .B gl\ \ \ \ \ -OpenGL video output driver. -Simple version, video size must be smaller than +OpenGL video output driver, simple version. +Video size must be smaller than the maximum texture size of your OpenGL implementation. -Intended to work even with the most simple OpenGL implementations. -But makes also use of newer extensions, allowing to support more -color spaces and DirectRendering. -Please use -dr if it works with your OpenGL implementations, since -for higher resolutions this provides a _big_ speedup. +Intended to work even with the most basic OpenGL implementations, +but also makes use of newer extensions, allowing to support more +color spaces and direct rendering. +Please use \-dr if it works with your OpenGL implementations, +since for higher resolutions this provides a +.B big +speedup. .PD 0 .RSs .IPs (no)manyfmts @@ -2683,10 +2685,14 @@ Enable or disable aspect scaling and pan-and-scan support (default: enabled). Disabling might increase speed. .IPs rectangle=<0,1,2> -Select if rectangular textures should be used (save video RAM, but often slower) -0: use power-of-two textures -1: use texture_rectangle -2: use texture_non_power_of_two +Select usage of rectangular textures (saves video RAM, but often slower). +.RSss +0: Use power-of-two textures. +.br +1: Use texture_rectangle. +.br +2: Use texture_non_power_of_two. +.REss .RE .PD 1 .
Diego Biurrun CVS wrote:
+Intended to work even with the most basic OpenGL implementations, +but also makes use of newer extensions, allowing to support more +color spaces and direct rendering.
"allowing to" is a mistake of some type; "allowing it to" would be better, but the result would still be something I'd have wanted to rephrase. How about "which allow support for"? Hmm. Vague memory (supported by a quick grep of the man page) indicate that we use "colorspace" so far; we might want to drop the internal space in that phrase, here. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. A government exists to serve its citizens, not to control them.
Hi, On Tue, Jul 26, 2005 at 04:54:53PM -0400, The Wanderer wrote:
Diego Biurrun CVS wrote:
+Intended to work even with the most basic OpenGL implementations, +but also makes use of newer extensions, allowing to support more +color spaces and direct rendering.
"allowing to" is a mistake of some type; "allowing it to" would be better, but the result would still be something I'd have wanted to rephrase. How about "which allow support for"?
Yes, I wanted to say "alowing it to", but only because I didn't have any better idea, I know it doesn't sound good.
Hmm. Vague memory (supported by a quick grep of the man page) indicate that we use "colorspace" so far; we might want to drop the internal space in that phrase, here.
Probably color-space would be more correct I guess (at least I am always told that you usually don't connect words directly in English). Greetings, Reiar Döffinger
Reimar Döffinger wrote:
Hi, On Tue, Jul 26, 2005 at 04:54:53PM -0400, The Wanderer wrote:
Diego Biurrun CVS wrote:
+Intended to work even with the most basic OpenGL implementations, +but also makes use of newer extensions, allowing to support more +color spaces and direct rendering.
"allowing to" is a mistake of some type; "allowing it to" would be better, but the result would still be something I'd have wanted to rephrase. How about "which allow support for"?
Yes, I wanted to say "alowing it to", but only because I didn't have any better idea, I know it doesn't sound good.
Does this mean that you're OK with my other suggestion?
Hmm. Vague memory (supported by a quick grep of the man page) indicate that we use "colorspace" so far; we might want to drop the internal space in that phrase, here.
Probably color-space would be more correct I guess (at least I am always told that you usually don't connect words directly in English).
Usually you don't, but there are always exceptions; that's how compound words arise. In this case, I'm simply extrapolating from the fact that the man page mentions "colorspace" ten times but "color.space" not at all; I wouldn't be 100% opposed to using either the space- or hyphen-separated form, although I sort of prefer the current usage, but if so we'd need to change it everywhere in the docs (and program output) rather than just in this one place. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. A government exists to serve its citizens, not to control them.
Hi, On Tue, Jul 26, 2005 at 06:26:56PM -0400, The Wanderer wrote:
Does this mean that you're OK with my other suggestion?
Please feel free to fix the docs completely to your liking, I won't complain. You really don't need to ask first. And as far as colorspace is concerned: just make it consistent, from way it looksI personnally prefer colorspace, but as German is my native language that's not much of a surprise *g* Greetings, Reimar Döffinger
On Tue, Jul 26, 2005 at 04:54:53PM -0400, The Wanderer wrote:
Diego Biurrun CVS wrote:
+Intended to work even with the most basic OpenGL implementations, +but also makes use of newer extensions, allowing to support more +color spaces and direct rendering.
"allowing to" is a mistake of some type; "allowing it to" would be better, but the result would still be something I'd have wanted to rephrase. How about "which allow support for"?
Go for it.
Hmm. Vague memory (supported by a quick grep of the man page) indicate that we use "colorspace" so far; we might want to drop the internal space in that phrase, here.
"colorspace" is the standard, yes. Feel free to directly commit these kind of changes without discussing them first, that's what we got you the CVS account for in the first place ;) Diego
Diego Biurrun wrote:
On Tue, Jul 26, 2005 at 04:54:53PM -0400, The Wanderer wrote:
Diego Biurrun CVS wrote:
+Intended to work even with the most basic OpenGL implementations, +but also makes use of newer extensions, allowing to support more +color spaces and direct rendering.
"allowing to" is a mistake of some type; "allowing it to" would be better, but the result would still be something I'd have wanted to rephrase. How about "which allow support for"?
Go for it.
Hmm. Vague memory (supported by a quick grep of the man page) indicate that we use "colorspace" so far; we might want to drop the internal space in that phrase, here.
"colorspace" is the standard, yes.
Feel free to directly commit these kind of changes without discussing them first, that's what we got you the CVS account for in the first place ;)
I do understand that, it's just that I don't yet have a sense for where to draw the line of "needs discussion" vs. "incontrovertible" (to coin a usage); for the moment I'm operating on the principle that, if I think that a change is something to which someone might object, I want to give people a chance to so object before making the commit. In the cases at hand, there were the additional issues that 1) I wanted to see if anyone had another suggestion for the phrasing, and 2) I wasn't entirely sure that "colorspace" was the correct form. I'll commit them on the morrow, when my Internet connection isn't being so confounded *slow*... -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. A government exists to serve its citizens, not to control them.
participants (4)
-
Diego Biurrun -
Reimar Döffinger -
syncmail＠mplayerhq.hu -
The Wanderer