dps-devel Mailing List for DPS (Page 7)
Status: Inactive
Brought to you by:
jch
You can subscribe to this list here.
2000 |
Jan
(20) |
Feb
(5) |
Mar
|
Apr
(4) |
May
(13) |
Jun
(3) |
Jul
(5) |
Aug
(7) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(34) |
Feb
(9) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(19) |
2004 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(5) |
2008 |
Jan
(3) |
Feb
(2) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
(11) |
Nov
(27) |
Dec
(42) |
2009 |
Jan
(25) |
Feb
(11) |
Mar
(17) |
Apr
(25) |
May
(92) |
Jun
(77) |
Jul
(28) |
Aug
(19) |
Sep
(20) |
Oct
(33) |
Nov
(10) |
Dec
(4) |
2010 |
Jan
(2) |
Feb
|
Mar
(36) |
Apr
(50) |
May
(76) |
Jun
(63) |
Jul
(48) |
Aug
(45) |
Sep
(21) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Masatake Y. <mas...@is...> - 2000-01-24 12:02:01
|
> > I'm swapping requests, events and errors, but I'm not doing anything > to the actual stream of data (as contained in the GiveInput requests > and the Output events). Do I need to? And should there be problems > on a local connection (LSBFirst to LSBFirst)? > You don't have to swap the data for GiveInput. I think DGS will be hint. dps_GiveInput in gsdpsx.c is handle GiveInput request. The data dgs received in dps_GiveInput is put to gs input stream(only copyed). So the gs can interpret the data dgs received in dps_GiveInput directly. * Compare the data dgs received in dps_GiveInput with the data dpsx received in ???. * You can give the binary encoded script to gs itself directly. Some approaches: 1. Write a binary encoded script. 2. Give it the gs itself directly. 3. Give it the dgs. 4. Give it the dpsx and put a trap at the ??? function and redirect the recetived data to a file. Then compare the file with the original script. If you find a difference between the file and the original script, there is a bug on the path between a client and dpsx. 5. Give the encoded script directly to the gs in dpsx. Anyway comparing dpsx with DGS will help you. DGS is not clean enough but it works. Masatake |
From: Juliusz C. <Jul...@en...> - 2000-01-24 11:19:02
|
>> The message I get is `syntax error in %ztokenexec'. I don't have >> problems with DGS. MY> ... Chech the byte order of connection between dpsx and clients. MY> DGS swaps the byte order of the data from a client. I'm swapping requests, events and errors, but I'm not doing anything to the actual stream of data (as contained in the GiveInput requests and the Output events). Do I need to? And should there be problems on a local connection (LSBFirst to LSBFirst)? Thanks for the hint, I'll check the documentation. J. |
From: Masatake Y. <mas...@is...> - 2000-01-24 10:33:32
|
> Sorry. I meant that I didn't manage to get Texteroids to work with my > extension code, and I don't understand the problem. As Texteroids > appears to work fine with DGS, I was wondering whether you had had any > similar problems, and what you had done to fix them. > > The message I get is `syntax error in %ztokenexec'. I don't have > problems with DGS. ... Chech the byte order of connection between dpsx and clients. DGS swaps the byte order of the data from a client. Masatake YAMATO |
From: Juliusz C. <Jul...@en...> - 2000-01-24 09:48:49
|
AF> The simplest way is to configure/make/install the core libraries with AF> the xdps backend; AF> configure --with-library-combo=gnu-gnu-gnu-xdps AF> make AF> make install Thanks. That works with Sun's server, but unfortunately doesn't with my extension. Is there any way to run the tests synchronously? AF> The xdps DPS code leaves much to be desired, however. Sure. What do you expect from what is basically a one-person effort that is two months old? I tried to be very clear, both in the README and on the web page, that this is very early code and that DGS is to be preferred for real work. J. |
From: Juliusz C. <Jul...@en...> - 2000-01-24 09:45:50
|
>> Did you need to do anything special in order to get texteroids to work >> with DGS? It would seem to me that texteroids hits a bug in the >> binary object parser of GhostScript, but I'm not sure. MY> I don't need to do anything special. Sorry. I meant that I didn't manage to get Texteroids to work with my extension code, and I don't understand the problem. As Texteroids appears to work fine with DGS, I was wondering whether you had had any similar problems, and what you had done to fix them. The message I get is `syntax error in %ztokenexec'. I don't have problems with DGS. J. |
From: Masatake Y. <mas...@is...> - 2000-01-24 05:53:18
|
> DPS.patch: updates the client library with information on the i386 > architecture. Disables some error checking in pswrap that happens to > be specific to AT&T lex and incompatible with flex. I create a tar.gz of dps client library maintained by dgs developers. http://www.gyve.org/~jet/xdps-1.0.tar.gz I'd like you to test this tar.gz file with dpsx and tell me the problem or send me a patch. I'll incorporate it. (I haven't compiled dpsx yet. I have to get the XFree86 source files.) Your modifications for lexer.l and dpsconfig.h in DPS.patch were already done by BALATON Zoltan<ba...@ei...>. See ChangeLog of xdps-1.0.tar.gz. Therefore I think I don't have to incorporate it. I applied your modification for FontSample.c. However your modification for is not applied to xdps-1.0. If xdps-1.0 works fine with dps, I'll put xdps-1.0 somewhere properly. Masatake YAMATO |
From: Adam F. <fe...@do...> - 2000-01-24 04:00:34
|
Juliusz Chroboczek wrote: > > By the way, could anyone tell me what needs to be done in order to run > the GNUstep tests with the xdps backend? > The simplest way is to configure/make/install the core libraries with the xdps backend; configure --with-library-combo=gnu-gnu-gnu-xdps make make install Then make the tests: cd Testing make They work more-or-less correctly with GNU DGS (Some have problems with blank windows because DPSWaitContext doesn't seem to work correctly (or maybe it's something else)). The xdps DPS code leaves much to be desired, however. -- Adam Fedor, Digital Optics | Fudd's law of opposition: Push fe...@do... | something hard enough, and it will fe...@gn... (GNUstep!) | fall over. |
From: Masatake Y. <mas...@is...> - 2000-01-24 02:21:56
|
I think someone has to act as message bridge between DPSX development and DGS development mailing list --- forward important messages from one mailing list to the other. If none will do, I'd like to do. Masatake YAMATO, je...@gy... |
From: Masatake Y. <mas...@is...> - 2000-01-24 02:16:50
|
Hi, > Did you need to do anything special in order to get texteroids to work > with DGS? It would seem to me that texteroids hits a bug in the > binary object parser of GhostScript, but I'm not sure. I don't need to do anything special. The current DGS bug that I know is occured when I resize a window of a client that uses multiple contexts. Could you tell me more detail? I'd like to see the ouput message. > By the way, could anyone tell me what needs to be done in order to run > the GNUstep tests with the xdps backend? I don't know well about xdps backend. If you needs DPS test programs, please check gtkDPS. http://www.gyve.org/gtkDPS/ Masatake YAMATO |
From: L. P. D. <gh...@al...> - 2000-01-23 07:39:48
|
> I don't know whether to make a distribution with this code now, or wait > for GhostScript 6.0. Mr Deutsch, any firm dates yet? We believe we have completed the testing on the image processing code that has been holding up the 6.0 release for about the last month, and this was the last piece of work we plan to do on the release. However, I cannot give you a firm release date. (I've been burned too many times by quoting dates before we actually had the software fully ready to ship.) Please check back with me in a week if the release hasn't been distributed by then. -- L. Peter Deutsch | Aladdin Enterprises gh...@al... | http://www.aladdin.com | 203 Santa Margarita Ave. +1-650-322-0103 (9-12 M-F) | fax +1-650-322-1734 | Menlo Park, CA 94025 The future of software is at http://www.opensource.org |
From: Juliusz C. <Jul...@en...> - 2000-01-23 07:27:17
|
Dear all, I've advanced somewhat the DPS extension. I've implemented swapped dispatch, and I've been able to get DPS clients from my Solaris/Sparc workstation to display on my Linux/Intel laptop. This should be convenient for testing. I've finally found the long-standing rendering bug: it was an overflow in the fixed_to_int_rnd family of macros (my bug, not Deutsch's). Dpsclock now displays correctly in all depths. Wonderland runs correctly (although a little slowly), except that there is a slight drawing artifact in the second demo (the Bezier curve). Another rendering bug? I don't know whether to make a distribution with this code now, or wait for GhostScript 6.0. Mr Deutsch, any firm dates yet? The main remaining problems are therefore the lack of time-slicing, and the single-context limitation. (By the way: contrary to what I said in the previous message, the usage of xdps is well documented. For some reason, though, the GNUstep demos don't run on my extension; they just hang.) J. |
From: Juliusz C. <Jul...@en...> - 2000-01-23 03:08:57
|
Dear Masa, Did you need to do anything special in order to get texteroids to work with DGS? It would seem to me that texteroids hits a bug in the binary object parser of GhostScript, but I'm not sure. By the way, could anyone tell me what needs to be done in order to run the GNUstep tests with the xdps backend? Thanks, J. |
From: Juliusz C. <Jul...@en...> - 2000-01-17 19:33:20
|
> 11. Build the DPS client library. You might need to patch it with > `DPS.patch' to get it to compile and run. MY> Juliusz, could you explain or write a ChangeLog entry for DPS.patch? MY> If worth, I'd like to incorporate your modification into dgs/DPS/*. DPS.patch: updates the client library with information on the i386 architecture. Disables some error checking in pswrap that happens to be specific to AT&T lex and incompatible with flex. MY> Could I help the XFree86 team to introduce the DPS client libraries. That would be great. Are you an XFree86 member? I guess you ought to coordinate this with Mark Vojkovich, who once proposed to help me with this task. J. |
From: Juliusz C. <Jul...@en...> - 2000-01-17 19:27:37
|
> 5. When a window is resised, the device space origin is not adjusted > to be at a constant position with respect to the window gravity; > instead, it remains at a constant position with respect to the > north-west corner. MY> ...I think it is worth to check dgs's gs/zmatrix.c and do grep '#ifdef MY> DISPLAYGHOSTSCIRPT'. I am not quite sure that I understand this code. In particular, the window offset doesn't seem to change at the time at which the window is resized, but only at the next CTM change. What is more, only the toplevel gstate is considered (nothing happens to the gstates that are lower on the gstate stack). Am I missing something? I don't know how to solve this problem, but at any rate I think that there are more urgent problems to solve. Getting scheduling and rendering to work correctly is of the highest priority. As to this problem, the only solution I can see right now is allocating a devPrivate on every window that holds the list of DPS devices associated with it, and wrapping the window resizing functions. When we get around to implementing this, we'll have to ask Keith Packard if he sees a better solution. Sincerely, Juliusz Chroboczek |
From: Masatake Y. <mas...@is...> - 2000-01-17 18:40:20
|
In README: > 11. Build the DPS client library. You might need to patch it with > `DPS.patch' to get it to compile and run. Juliusz, could you explain or write a ChangeLog entry for DPS.patch? If worth, I'd like to incorporate your modification into dgs/DPS/*. It is very easy to release dgs/DPS separated from dgs. > 2. Create a directory `$SRC/xc/include/DPS' and copy into it the files > `XDPS.h' and `XDPSproto.h' from `$SRC/DPS/include/DPS'. Note that > this might or might not be needed in future versions of XFree86 (which > might or might not include the DPS client libraries). Could I help the XFree86 team to introduce the DPS client libraries. Some members at GYVE have improved DPS client libraries. I'd like to reflect them to the DPS distributions from XFree86. Masatake YAMATO |
From: Masatake Y. <mas...@is...> - 2000-01-17 18:29:44
|
In README: > > 5. When a window is resised, the device space origin is not adjusted > to be at a constant position with respect to the window gravity; > instead, it remains at a constant position with respect to the > north-west corner. > ...I think it is worth to check dgs's gs/zmatrix.c and do grep '#ifdef DISPLAYGHOSTSCIRPT'. Masatake YAMATO |
From: Masatake Y. <mas...@is...> - 2000-01-16 23:50:06
|
Hi, I've just joined this list. Masatake YAMATO, a developer of the GYVE |