plib-devel Mailing List for PLIB (Page 31)
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(80) |
Mar
(128) |
Apr
(111) |
May
(157) |
Jun
(70) |
Jul
(116) |
Aug
(465) |
Sep
(574) |
Oct
(325) |
Nov
(163) |
Dec
(182) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(167) |
Feb
(191) |
Mar
(319) |
Apr
(118) |
May
(252) |
Jun
(427) |
Jul
(187) |
Aug
(96) |
Sep
(219) |
Oct
(161) |
Nov
(109) |
Dec
(210) |
| 2002 |
Jan
(97) |
Feb
(80) |
Mar
(143) |
Apr
(234) |
May
(72) |
Jun
(246) |
Jul
(155) |
Aug
(280) |
Sep
(418) |
Oct
(81) |
Nov
(72) |
Dec
(88) |
| 2003 |
Jan
(59) |
Feb
(63) |
Mar
(33) |
Apr
(27) |
May
(87) |
Jun
(50) |
Jul
(97) |
Aug
(45) |
Sep
(35) |
Oct
(67) |
Nov
(78) |
Dec
(13) |
| 2004 |
Jan
(167) |
Feb
(144) |
Mar
(172) |
Apr
(93) |
May
(43) |
Jun
(7) |
Jul
(27) |
Aug
(36) |
Sep
(48) |
Oct
(54) |
Nov
(5) |
Dec
(44) |
| 2005 |
Jan
(53) |
Feb
(36) |
Mar
(13) |
Apr
(3) |
May
(19) |
Jun
|
Jul
(49) |
Aug
(39) |
Sep
(8) |
Oct
(8) |
Nov
(51) |
Dec
(23) |
| 2006 |
Jan
(26) |
Feb
(5) |
Mar
(26) |
Apr
(26) |
May
(52) |
Jun
(36) |
Jul
(8) |
Aug
(12) |
Sep
(6) |
Oct
(75) |
Nov
(34) |
Dec
(25) |
| 2007 |
Jan
(46) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
(2) |
Aug
|
Sep
(40) |
Oct
(9) |
Nov
(3) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(26) |
Apr
|
May
|
Jun
(2) |
Jul
(4) |
Aug
(6) |
Sep
|
Oct
|
Nov
(5) |
Dec
(2) |
| 2009 |
Jan
(63) |
Feb
(4) |
Mar
(12) |
Apr
|
May
(5) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(14) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Melchior F. <mf...@us...> - 2005-07-09 12:07:59
|
* Melchior FRANZ -- Thursday 07 July 2005 22:58: > The attached patch uses PUCOL_LABEL for text, and (PUCOL_BACKGROUND-PUCOL_LABEL)/2 > for selected text. This assumes that background and text have good contrast > against each other, and something in between differs enough from either, while > still being legible. Could this, please, be considered anyway, independent of my qualities as "lawyer" or lack thereof? puComboBox has a similar problem: it doesn't propagate its own color to its children. Would you accept a patch? m. |
|
From: Melchior F. <mf...@us...> - 2005-07-09 12:04:11
|
* Steve Baker -- Saturday 09 July 2005 04:52:
> There is no explicit protection for fonts or typeface designs in US or European
> copyright laws. Some people have patented their fonts - others have tried to use
> trademark law - but copyrights do not apply.
Right. There's no copyright for font/glyph *design*. I think I could take a
font that I like and make a similar/equal one. Emphasize on *make*. For taking
a font (which, as file, *is* AFAIK copyright protected, just not as design),
and converting it (into a form that is still a font), I need the permission of
the owner. Which we certainly have, given that these fonts are free (part of
XFree :-).
But the situation really is:
Helvetica . . . . . . . . . . . > fntBitmapFont.cxx/plib
(c) Adobe Helvetica parts: (c) PWO? really?
| ^
|________________genfonts_______________|
(c) PWO
And here I just don't see how the original Helvetica font can suddenly be
(c) PWO. Imagine the same process with an "electronic book", and running
pdftotext on it. It lost formatting (and write protection ;-), and all
link/hyperref capabilities, but in essence it's still the original work.
Now, would the book suddenly become copyright of "Glyph & Cog" (the
copyright holder of pdftotext)? Probably not. Even if pdftotext would
write a message into the output file claiming so. But who cares ...
m.
PS: I apologize to all for my impolite replies, especially to Andy. I took
the first sign of a counter argument and only replied to that, while
ignoring the rest. Bad style! And I just wanted to annoy Hornets, not
getting stung. :-)
|
|
From: Steve B. <sjb...@ai...> - 2005-07-09 01:03:13
|
> The file fnt/fntBitmap.cxx contains data of seven fonts. Above that there's > a copyright message by the author of the genfonts utility, where he claims > ownership of copyright and grants permissions. Very generous and all, but: > he doesn't really own anything in this file! These are fonts that are > "Copyright by Adobe Systems Incorporated and Digital Equipment Corporation > (All Rights Reserved.)" There is no explicit protection for fonts or typeface designs in US or European copyright laws. Some people have patented their fonts - others have tried to use trademark law - but copyrights do not apply. Things may be different in other juristictions, but being legal everywhere on the planet is generally impossible anyway. They can license the actual files - and limit what the licensee does with them, but converting a font from vector to bitmap means we've simply rendered the font - which is OK. I don't think there are legal issues here. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Andy R. <an...@pl...> - 2005-07-08 17:49:50
|
Melchior FRANZ wrote: > So running hexdump over a binary makes the output my work? Oh sure. > See you in court. OK, Stop this now. You're just flaming to hear yourself yell. I never said that. What I did say was: placing that hexdump inside a file containing other, meaningful content creates a combined work covered by the copyrights of both authors. If the license terms of the original font are LGPL compatible, then just put a dual copyright notice at the top of the file and stop this meaningless argument. If they are not LGPL compatible, then yank them as plib can't redistribute them anyway. Andy |
|
From: Melchior F. <mf...@us...> - 2005-07-08 17:33:37
|
* Andy Ross -- Friday 08 July 2005 19:25: > Melchior FRANZ wrote: > > The mere conversion of data does *not* change license and copyright! > > Sure it does. The converted file format is a new work, and has its > own copyright. So running hexdump over a binary makes the output my work? Oh sure. See you in court. Again: if the original distribution terms allow modification and redistribution (which is certainly the case here), then I may *add* my copyright. But never may I remove/replace or change copyright or terms. Only add. And this does AFAIK not apply to automatically converted stuff. Running gzip over the file makes it mine? Dream on ... m. --EOT-- |
|
From: Andy R. <an...@pl...> - 2005-07-08 17:25:32
|
Melchior FRANZ wrote: > The mere conversion of data does *not* change license and copyright! Sure it does. The converted file format is a new work, and has its own copyright. You seem to be under the impression that a single "file" (or whatever) can carry only one copyright. That is incorrect. The original work is the property of the font author, the changes involved generated file is the property of whoever ran the conversion tool. The combined work must be distributed within the licence granted by both parties. This kind of thing happens all the time. It is *very* common for files in the commercial world to carry multiple copyrights at the top. Remember also that the copyright notice is only a formality, under the Berne conventions. The existence of copyright is automatic, and not dependent on registration or claim. Putting the notice at the top is just evidence for future litigation; it shows that the original author believed that the work was his/her/its property. Just put a multi-copyright note at the top and all will be well. There is nothing illegal going on here, so long as Plib's and the fonts license requiresments are compatible. Andy |
|
From: Melchior F. <mf...@us...> - 2005-07-08 17:14:21
|
* Andy Ross -- Friday 08 July 2005 18:56: > It's actually not wrong to claim copyright on the generated file. You > generated it, not Bitstream or Adobe or whoever. That's AFAIK wrong. You may add your copyright (if you made substantial changes?). Hey, that's what I did to the conversion utility! But you must not replace the original by yours. And you must not change the license, distribution terms etc. The mere conversion of data does *not* change license and copyright! > In practice, though, the fonts are freely redistributable in many > formats (X11 bitmaps, for example) that don't even provide the ability > to notate a copyright attribution. That's encoded in the font file: $ gunzip -c /usr/X11R6/lib/X11/fonts/75dpi/helvR14-ISO8859-1.pcf.gz|strings|grep Copyright Copyright (c) 1984, 1987 Adobe Systems Incorporated. All Rights Reserved. \ Copyright (c) 1988, 1991 Digital Equipment Corporation. All Rights Reserved. As there are no distribution terms, permissions, etc. given, we have to assume that those of the whole Xorg/XFree distribution are to be applied. See: $ find /usr/X11R6/|grep LICENSE /usr/X11R6/lib/X11/doc/LICENSE > Simply including those formats isn't really a serious error, IMHO. > But it's easy to correct. Well, now that I brought this up on a public list, nobody can say he didn't know. It's in the archives. Sorry for that. ;-) Damn, I said I wouldn't care about that at all. Now it looks as if I do. I don't! m. :-) |
|
From: Andy R. <an...@pl...> - 2005-07-08 16:56:32
|
Melchior FRANZ wrote: > Well, what GLUT does or does not do, is secondary. I don't really > think that there is an immediate threat. But it's clearly a > copyright violation and as such not exactly desirable. It's actually not wrong to claim copyright on the generated file. You generated it, not Bitstream or Adobe or whoever. The data in the file *also* represents a font that is in someone else's copyright, though, so simply adding the font owner's copyright to the top of the file is sufficient. Something like this is perfectly legal: // Copyright 1999, 2005 Steve & Melchior // Font data Copyright <whenvever> Adobe Systems Inc. // Font data Copyright <whenvever> Bitstream, Inc. // Font data Copyright <whenvever> FooFoundry.com, Inc. In practice, though, the fonts are freely redistributable in many formats (X11 bitmaps, for example) that don't even provide the ability to notate a copyright attribution. Simply including those formats isn't really a serious error, IMHO. But it's easy to correct. Andy |
|
From: Melchior F. <mf...@us...> - 2005-07-08 14:57:15
|
* Fay John F Contr AAC/WMG -- Friday 08 July 2005 16:34: > It is indeed a beautiful day today. If I may misquote a twenty-year-old > movie [...] I was actually inspired by this quote: I think it's a beautiful day to go to the zoo and feed the ducks. To the lions. -- Brian Kantor :-) > I think I will wait for Steve's response on this one. The "freeglut" file > status is even more vague because it has had stuff added from the OpenGLUT > library. GLUT, by the way, doesn't say anything about other people's > copyrights on the bitmap fonts. Well, what GLUT does or does not do, is secondary. I don't really think that there is an immediate threat. But it's clearly a copyright violation and as such not exactly desirable. Would we complain about someone else violating plib's/freeglut's license? Certainly! And I think that *omitting* the copyright message is one thing, but replacing it by someone else's is almost criminal. Like taking an arbitrary book, removing all signs of the original author, and distributing it as if I had written it. I don't like the term "Intellectual Property", even less "IP theft". But the OSS community does all the time have to fight against these accusations. In this case there's nothing to argue, I'm afraid. m. |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-08 14:35:34
|
Oh, dear!
It is indeed a beautiful day today. If I may misquote a twenty-year-old
movie ("Romancing the Stone"), "What did you do, lady, wake up this morning
and decide, 'Today I'm going to ruin some guy's life'?" I just mentioned on
the "freeglut" list that there is a Category 4 hurricane headed in my
direction (should be Category 3 by the time it gets here ... knock on wood)
so if you want anything from me you'd better get to it in the next seven
hours or so.
I think I will wait for Steve's response on this one. The "freeglut" file
status is even more vague because it has had stuff added from the OpenGLUT
library. GLUT, by the way, doesn't say anything about other people's
copyrights on the bitmap fonts. It does give Sun Microsystems copyright
info for the stroke fonts.
John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior FRANZ
Sent: Friday, July 08, 2005 4:40 AM
To: pli...@li...
Cc: Pawel W. Olszta
Subject: [Plib-devel] legal matters
It's a beautiful day today, so I thought "why not stir up a hornet's nest?".
Just for fun. :-P
The file fnt/fntBitmap.cxx contains data of seven fonts. Above that there's
a copyright message by the author of the genfonts utility, where he claims
ownership of copyright and grants permissions. Very generous and all, but:
he doesn't really own anything in this file! These are fonts that are
"Copyright by Adobe Systems Incorporated and Digital Equipment Corporation
(All Rights Reserved.)" IANAL, but this doesn't look good to me. How can
the author of a font conversion utility turn the copyright of converted
fonts into his own? He owns the rights to the converter utility. Only!
Nothing more. Nothing less. The generated fonts are derived work and still
copyright by Adobe and DEC. (Or do I miss something?)
I think it would be a good idea for plib (and freeglut!) to remove these
illegal copyright messages, and put the real ones in. That's what we did
in FlightGear, where we use a modified version of genfonts, too[1]. The
generated file fonts.cxx[2] credits Adobe/DEC and Bitstream, as I think it
should. (I assume that the use of Helvetica in this way per se is allowed.
It surely is for the Bitstream fonts.)
Note that I don't want to teach anybody anything. I don't really care much
about this issue in the plib & freeglut context (and I won't tell
Adobe/DEC).
But I *do* care about FlightGear, and thought that you might be interested
in this theory. :-)
m.
PS: In case you are interested in what we are doing to plib and with it,
here are some screenshots:
http://members.aon.at/mfranz/fgfs_gui.jpg [78 kB]
http://members.aon.at/mfranz/fgfs_gui2.jpg [215 kB]
http://members.aon.at/mfranz/fgfs_gui6.jpg [264 kB]
[1]
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/utils/gui/g
enfonts.c?rev=1.1&cvsroot=FlightGear-0.9&content-type=text/vnd.viewcvs-marku
p
[2]
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/src/GUI/fon
ts.cxx?rev=1.2&cvsroot=FlightGear-0.9&content-type=text/vnd.viewcvs-markup
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel
|
|
From: Melchior F. <mf...@us...> - 2005-07-08 09:40:32
|
It's a beautiful day today, so I thought "why not stir up a hornet's nest?".
Just for fun. :-P
The file fnt/fntBitmap.cxx contains data of seven fonts. Above that there's
a copyright message by the author of the genfonts utility, where he claims
ownership of copyright and grants permissions. Very generous and all, but:
he doesn't really own anything in this file! These are fonts that are
"Copyright by Adobe Systems Incorporated and Digital Equipment Corporation
(All Rights Reserved.)" IANAL, but this doesn't look good to me. How can
the author of a font conversion utility turn the copyright of converted
fonts into his own? He owns the rights to the converter utility. Only!
Nothing more. Nothing less. The generated fonts are derived work and still
copyright by Adobe and DEC. (Or do I miss something?)
I think it would be a good idea for plib (and freeglut!) to remove these
illegal copyright messages, and put the real ones in. That's what we did
in FlightGear, where we use a modified version of genfonts, too[1]. The
generated file fonts.cxx[2] credits Adobe/DEC and Bitstream, as I think it
should. (I assume that the use of Helvetica in this way per se is allowed.
It surely is for the Bitstream fonts.)
Note that I don't want to teach anybody anything. I don't really care much
about this issue in the plib & freeglut context (and I won't tell Adobe/DEC).
But I *do* care about FlightGear, and thought that you might be interested
in this theory. :-)
m.
PS: In case you are interested in what we are doing to plib and with it,
here are some screenshots:
http://members.aon.at/mfranz/fgfs_gui.jpg [78 kB]
http://members.aon.at/mfranz/fgfs_gui2.jpg [215 kB]
http://members.aon.at/mfranz/fgfs_gui6.jpg [264 kB]
[1] http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/utils/gui/genfonts.c?rev=1.1&cvsroot=FlightGear-0.9&content-type=text/vnd.viewcvs-markup
[2] http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/src/GUI/fonts.cxx?rev=1.2&cvsroot=FlightGear-0.9&content-type=text/vnd.viewcvs-markup
|
|
From: Melchior F. <mf...@us...> - 2005-07-07 20:58:50
|
The puListBox uses black as textcolor, no matter what the color scheme is. This makes the text very hard to read on dark backgrounds. Likewise, selected text is hardcoded to be white. The attached patch uses PUCOL_LABEL for text, and (PUCOL_BACKGROUND-PUCOL_LABEL)/2 for selected text. This assumes that background and text have good contrast against each other, and something in between differs enough from either, while still being legible. m. |
|
From: Jan R. <slo...@gm...> - 2005-07-07 18:07:56
|
Am Wed, 06 Jul 2005 20:11:55 +0200 schrieb Bram Stolk <br...@sa...>: > Jan Reucker wrote: > > Hello, > > > > I've posted this mail to the plib-users list about six weeks ago, > > but got no reply. I'll repost it here and hope that someone can > > reproduce or maybe even fix the problem: > > When building from current CVS, the 'water' example works for me. > What GL renderer are you using? (glxinfo will tell you). Hello Bram, I think I've found the reason. By exchanging the 1.8.4 libs against their 1.8.3 counterparts I found out that the problem is within ssgAux. Looking at the difference between 1.8.3 and 1.8.4 it must be a change in the pre- and post-drawing callbacks of ssgaFire. I confirmed that by removing the fire from the water demo and linking against ssgaux 1.8.4 --> problem is gone, lighting works again. Looking at the CVS I noticed that the critical piece of code was changed again, and linking against the CVS version also works for me. Thx! Jan R. -- Jan Reucker email: jan dot reucker at web dot de web: http://www.reucker-online.de |
|
From: Bram S. <br...@sa...> - 2005-07-06 18:12:07
|
Jan Reucker wrote:
> Hello,
>
> I've posted this mail to the plib-users list about six weeks ago,
> but got no reply. I'll repost it here and hope that someone can
> reproduce or maybe even fix the problem:
When building from current CVS, the 'water' example works for me.
What GL renderer are you using? (glxinfo will tell you).
Bram
|
|
From: Jan R. <slo...@gm...> - 2005-07-06 17:20:27
|
Hello, I've posted this mail to the plib-users list about six weeks ago, but got no reply. I'll repost it here and hope that someone can reproduce or maybe even fix the problem: I've noticed that there seems to be a problem with the water demo in the plib examples pack. I can recall that using the 1.8.1 examples and linking it against 1.8.3 worked fine. Now I compiled the demos again, linking them with 1.8.4. All ssg demos look fine except the water demo. It seems to lack proper lighting. All objects are only dark shapes. Switching to wireframe mode works fine, but there seems to be no lighting. All "wires" are equally black. I've tested this on my Linux machine (Debian, 2.6.10, NVidia card and drivers) and on a WinXP machine (with some onboard Intel graphics adapter). I've recently tried to fix this on my own by playing around with the position and colors of the light source, but this didn't seem to change anything. Any ideas? Kind regards, Jan R. -- Jan Reucker email: jan dot reucker at web dot de web: http://www.reucker-online.de |
|
From: Melchior F. <mf...@us...> - 2005-07-06 10:53:09
|
* Steve Baker -- Wednesday 06 July 2005 03:48: > When you render the bitmap, it's positioned at that vertex and rendered > at 1:1 pixel size and parallel to the edges of the screen no matter what. > > So the size and resolution of the bitmap are independent of Z - perspective > only affects the position of the corner of the bitmap - not the size of > the bits when rendered onscreen. OK. That was my original assumption. So, bitmap fonts/characters are done in integer operations only. glBitmap's "width" and "height" arguments are already integers, but how is the position handled? Automatically converted to integers by OpenGL? And the "gap" value (that still waits for implementation)? This is a float now, but should internally really be an integer, too, right? Otherwise we'd get a problem with getBBox, which does internally work with integers only. As I said in a previous message: I would have sent a patch for the gap bug (i.e. the fact that plib pretends to offer gap functionality for fntTexFont, but doesn't implement it). But I don't know how to deal with this int/float thing. In the worst case I work around the bug and simply apply the desirable amount of gap to the compiled bitmap font. I just need to know. m. |
|
From: Steve B. <sjb...@ai...> - 2005-07-05 23:59:30
|
Melchior FRANZ wrote: > * Bram Stolk -- Tuesday 05 July 2005 12:56: > >>If z-test is off, and z-buffer writes are off, my guess is that >>the z coord does not matter. > > I don't think that z is useful for fntBitmapFonts at all. Their main > advantage is the non-blurry, sharp look. They would probably become > illegible with any non-zero z. No - that's not how glBitmaps work. You give it *one* vertex position in x,y,z - which is then transformed as if it was an ordinary vertex (and culled if it's off-screen). When you render the bitmap, it's positioned at that vertex and rendered at 1:1 pixel size and parallel to the edges of the screen no matter what. So the size and resolution of the bitmap are independent of Z - perspective only affects the position of the corner of the bitmap - not the size of the bits when rendered onscreen. The only time Z might matter would be if you still had perspective enabled (which you don't in PUI) - then it's possible for the Z coord to come out closer than Znear or further than Zfar - which would result in the position command being set 'offscreen' and the bitmap not being drawn. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Bram S. <br...@sa...> - 2005-07-05 16:18:57
|
Argh... sorry It turns out that indeed I dont understand these matters. start3f() is available, yet when z-coord is not null, the text is not visible. Bram |
|
From: Bram S. <br...@sa...> - 2005-07-05 16:08:58
|
Bram Stolk wrote: > So I think we just broke the 'fonts with depth' in plib :-( ...where it not for the fact that the start3f() is missing, and we only have a start2f(), so it was never available in the first place. text with depth would need an extra member on fntRenderer class. If this is desired, I'll add support for it, if not, we can leave this as is, and have a working fnt system that works with negative coords, but not with depths != 0. Steve's pick I would say. Bram |
|
From: Bram S. <br...@sa...> - 2005-07-05 15:57:45
|
Melchior FRANZ wrote: > * Bram Stolk -- Tuesday 05 July 2005 12:56: > >>If z-test is off, and z-buffer writes are off, my guess is that >>the z coord does not matter. > > > I don't think that z is useful for fntBitmapFonts at all. Their main > advantage is the non-blurry, sharp look. They would probably become > illegible with any non-zero z. Also, positions of type float don't > seem to make much sense. I know that this is necessary for inheritance > from fntFont, but they should probably be explicitly converted to integers. huh... either I don't understand this, or this is incorrect. I'm pretty sure that z-testing for glWritePixels and glBitmap is available if the programmer does not disable it, and fragments are written with current z-coord. I dont see why they would become illegible with non zero z. bitmap pixels are treated similarly to polygon fragments. Although unusual, my guess is that text with depth, e.g. menus in the fog :-) is perfectly feasible. I've commited the 2i version, but the 3f is more correct I think. So I think we just broke the 'fonts with depth' in plib :-( I suggest going back to 3 components, thus: glRasterPos3f(0,0,curpos[2]) Also, I extended the font test with the special case of negative coords. Bram > > And then: fntBitmap don't consider the gap value, which makes setGap() > and getGap() useless. I'd need the gap, though, and added it where > necessary. But here again the question arises: should gaps be allowed > to be floats? I'd convert them to integers before applying. I'll > provide another patch if I know the opinion of the plib developers > on this int/float question. > > m. > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Melchior F. <mf...@us...> - 2005-07-05 14:56:22
|
* Bram Stolk -- Tuesday 05 July 2005 12:56: > If z-test is off, and z-buffer writes are off, my guess is that > the z coord does not matter. I don't think that z is useful for fntBitmapFonts at all. Their main advantage is the non-blurry, sharp look. They would probably become illegible with any non-zero z. Also, positions of type float don't seem to make much sense. I know that this is necessary for inheritance from fntFont, but they should probably be explicitly converted to integers. And then: fntBitmap don't consider the gap value, which makes setGap() and getGap() useless. I'd need the gap, though, and added it where necessary. But here again the question arises: should gaps be allowed to be floats? I'd convert them to integers before applying. I'll provide another patch if I know the opinion of the plib developers on this int/float question. m. |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-05 14:24:03
|
Gentlemen, I just went to the SourceForge web site and noticed an ad from ... Microsoft ... for Microsoft Visual Studio 2005. John F. Fay Technical Fellow, Jacobs/Sverdrup TEAS Group joh...@eg... 850-729-6330 |
|
From: Melchior F. <mf...@us...> - 2005-07-05 12:50:15
|
* Bram Stolk -- Tuesday 05 July 2005 12:56: > In any case, I think that these issues warrant a more > complex fnt test in examples. Do you have a nice fnt tst > program for us we can use in examples/src/fnt ? > (one with negative coords of course) Umm ... FlightGear would be too big, no? :-} Unfortunately, this is my only test app so far. m. |
|
From: Bram S. <br...@sa...> - 2005-07-05 10:56:36
|
Melchior FRANZ wrote: > I had responded immediately after my first message showed up on the > list, but then I used the wrong mail address. And the bloody sf.net > server didn't complain, so it took me a while to notice. Here again: > > The patch from yesterday wasn't complete: it hadn't considered, that > the same bug would happen in puts() after "\n", and also in putch(). > The attached patch fixes that, too. > > But I'm not sure if I did it right. I set the RasterPos only with 2i, > assuming that the z-component would be zero in all cases. Is this true? > Or should I rather have used: glRasterPos3f(0.0f, 0.0f, curpos[2]) > in all three cases instead? Uh... I think this depends wether z-tests are done when writing the text? If z-test is off, and z-buffer writes are off, my guess is that the z coord does not matter. In any case, I think that these issues warrant a more complex fnt test in examples. Do you have a nice fnt tst program for us we can use in examples/src/fnt ? (one with negative coords of course) Bram > > m. > > > ------------------------------------------------------------------------ > > Index: fntBitmap.cxx > =================================================================== > RCS file: /cvsroot/plib/plib/src/fnt/fntBitmap.cxx,v > retrieving revision 1.2 > diff -u -p -r1.2 fntBitmap.cxx > --- fntBitmap.cxx 4 Jul 2005 14:58:54 -0000 1.2 > +++ fntBitmap.cxx 5 Jul 2005 06:00:35 -0000 > @@ -71,7 +71,8 @@ void fntBitmapFont::putch ( sgVec3 curpo > if (c == '\n') { > curpos[1] -= height; > } else { > - glRasterPos3fv(curpos); > + glRasterPos2i(0, 0); > + glBitmap(0, 0, 0, 0, curpos[0], curpos[1], NULL); > int i = (GLubyte) c - first; > if (i >= 0 && i < count) { > glBitmap(data[i][0], height, xorig, yorig, (float) data[i][0], 0, data[i] + 1); > @@ -90,7 +91,8 @@ void fntBitmapFont::puts ( sgVec3 curpos > if (s[i] == '\n') { > curpos[0] = x0; > curpos[1] -= height; > - glRasterPos3fv(curpos); > + glRasterPos2i(0, 0); > + glBitmap(0, 0, 0, 0, curpos[0], curpos[1], NULL); > } else { > int j = (GLubyte) s[i] - first; > if (j >= 0 && j < count) { |
|
From: Jim C. <j.c...@zy...> - 2005-07-05 09:17:41
|
Hi,
I have re-posted this as may have got lost somewhere - sorry if you get
duplicate.
I am just joining plib devel in order to suggest some modifications to
joystick
handling in MacOSX for use in FlightGear.
I am just looking at the USB "HID Usage tables" specification and for
Generic Desktop
there are a few other useful things that might be reported by a
joystick or gamepad and
also keypad and Multi-Axis-controller. Maybe we need the
"multi-access-controller' application
and "wheel" dynamic for example? I have already added and submitted to
flightgear the
kHIDUsage_GD_Dial to jsMacOSX.cxx as this is reported by my Saitek X45
joystick but
it needs to be more general.
/* GenericDesktop Page (0x01) */
enum
{
kHIDUsage_GD_Pointer = 0x01, /* Physical Collection */
kHIDUsage_GD_Mouse = 0x02, /* Application Collection */
/* 0x03 Reserved */
kHIDUsage_GD_Joystick = 0x04, /* Application Collection */
kHIDUsage_GD_GamePad = 0x05, /* Application Collection */
kHIDUsage_GD_Keyboard = 0x06, /* Application Collection */
kHIDUsage_GD_Keypad = 0x07, /* Application Collection */
kHIDUsage_GD_MultiAxisController = 0x08, /* Application Collection */
/* 0x09 - 0x2F Reserved */
kHIDUsage_GD_X = 0x30, /* Dynamic Value */
kHIDUsage_GD_Y = 0x31, /* Dynamic Value */
kHIDUsage_GD_Z = 0x32, /* Dynamic Value */
kHIDUsage_GD_Rx = 0x33, /* Dynamic Value */
kHIDUsage_GD_Ry = 0x34, /* Dynamic Value */
kHIDUsage_GD_Rz = 0x35, /* Dynamic Value */
kHIDUsage_GD_Slider = 0x36, /* Dynamic Value */
kHIDUsage_GD_Dial = 0x37, /* Dynamic Value */
kHIDUsage_GD_Wheel = 0x38, /* Dynamic Value */
kHIDUsage_GD_Hatswitch = 0x39, /* Dynamic Value */
also for future reference there is a "Simulation Page" which if we can
make our own
USB "cockpit" device may be useful. For example the following (and
more!) are
specifically mentioned:
/* Simulation Page (0x02) */
/* This section provides detailed descriptions of the usages employed
by simulation devices. */
enum
{
kHIDUsage_Sim_FlightSimulationDevice = 0x01,/* Application Collection
*/
kHIDUsage_Sim_AutomobileSimulationDevice= 0x02,/* Application
Collection */
kHIDUsage_Sim_TankSimulationDevice = 0x03,/* Application Collection */
kHIDUsage_Sim_SpaceshipSimulationDevice= 0x04,/* Application
Collection */
kHIDUsage_Sim_SubmarineSimulationDevice= 0x05,/* Application
Collection */
kHIDUsage_Sim_SailingSimulationDevice = 0x06,/* Application Collection
*/
kHIDUsage_Sim_MotorcycleSimulationDevice= 0x07,/* Application
Collection */
kHIDUsage_Sim_SportsSimulationDevice = 0x08, /* Application Collection
*/
kHIDUsage_Sim_AirplaneSimulationDevice= 0x09, /* Application
Collection */
kHIDUsage_Sim_HelicopterSimulationDevice= 0x0A,/* Application
Collection */
kHIDUsage_Sim_MagicCarpetSimulationDevice= 0x0B,/* Application
Collection */
kHIDUsage_Sim_BicycleSimulationDevice = 0x0C,/* Application Collection
*/
/* 0x0D - 0x1F Reserved */
kHIDUsage_Sim_FlightControlStick = 0x20,/* Application Collection */
kHIDUsage_Sim_FlightStick = 0x21, /* Application Collection */
kHIDUsage_Sim_CyclicControl = 0x22, /* Physical Collection */
kHIDUsage_Sim_CyclicTrim = 0x23, /* Physical Collection */
kHIDUsage_Sim_FlightYoke = 0x24, /* Application Collection */
kHIDUsage_Sim_TrackControl = 0x25, /* Physical Collection */
/* 0x26 - 0xAF Reserved */
kHIDUsage_Sim_Aileron = 0xB0, /* Dynamic Value */
kHIDUsage_Sim_AileronTrim = 0xB1, /* Dynamic Value */
kHIDUsage_Sim_AntiTorqueControl = 0xB2,/* Dynamic Value */
kHIDUsage_Sim_AutopilotEnable = 0xB3, /* On/Off Control */
kHIDUsage_Sim_ChaffRelease = 0xB4, /* One-Shot Control */
kHIDUsage_Sim_CollectiveControl = 0xB5,/* Dynamic Value */
kHIDUsage_Sim_DiveBrake = 0xB6, /* Dynamic Value */
etc. etc.
cheers
Jim
|
34 messages has been excluded from this view by a project administrator.
