| | <<<Back 1 day (to 2011/07/24) | 2011/07/25 |
| cryptopsy | what is ps2ps2? | 09:48.46 |
| kens | PostScritp to PostScript level 2. It uses the ps2write device. Its now the same as ps2ps or pdf2ps. | 09:49.18 |
| cryptopsy | is it different from ps2pah , lvl2 | 09:49.25 |
| | whoops | 09:49.39 |
| | that was a jumbled of mess | 09:49.46 |
| | so was that .. | 09:50.02 |
| | thanks | 09:50.17 |
| kens | NP | 09:50.21 |
| cryptopsy | how can i get ps2sacii to produce the nice formatting (tabs, spacing) that ps2pdf produces? | 09:51.36 |
| kens | Huh ? Ps2pdf creates PDF files..... | 09:51.57 |
| cryptopsy | ultimately i just want to convert man pages to text files with the exact same formatting | 09:52.04 |
| kens | Try the brand new txtwrite device, just committed this morning | 09:52.21 |
| | And be aware that this is not actually a simple problem to solve. | 09:52.51 |
| ghostgum | nroff -man input.1 | 09:55.34 |
| cryptopsy | ? | 09:55.59 |
| Robin_Watts | cryptopsy: man pages are in nroff format. | 09:56.18 |
| | so you can convert to text as ghostgum says, without needing to go via pdf or postscript. | 09:56.46 |
| ghostgum | That command (from memory) gives you a text file output, with lots of ^H backspaces for bold and overprint. | 09:56.52 |
| cryptopsy | man's "-t" parameter uses groff -Tps -mandoc to format the man page, -T is the type and there is ascii and utf8 which both loses the tabs | 09:57.13 |
| ghostgum | There are a number of text to PostScript converters that can handle that and produce PS with bold and underlines. | 09:57.14 |
| cryptopsy | i dont care about bold and underlines | 09:57.33 |
| ghostgum | Or you can just strip out the unwanted backspaces with bold/underlines using sed. | 09:57.48 |
| cryptopsy | i just want indentation | 09:58.03 |
| chrisl | cryptopsy: try "man ls | col -bx > ls.txt" | 09:58.15 |
| cryptopsy | that also does not work | 09:58.32 |
| malc_ | cryptopsy: http://mdocml.bsd.lv/ , http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk204.ogg | 09:58.40 |
| Robin_Watts | kens: So are you free from the txtwrite thing then ? | 09:58.48 |
| chrisl | cryptopsy: hmm, works for me..... | 09:58.59 |
| kens | Robin_Watts : yes, but now Marcos has asked me to look at the customer problem with handles. | 09:59.08 |
| cryptopsy | chrisl: doens't process certain symbols | 09:59.19 |
| Robin_Watts | "does not work" is not a helpful bug report :( | 09:59.20 |
| malc_ | Robin_Watts: has good signal to noise ratio though | 09:59.35 |
| Robin_Watts | kens: Ah, well. Let me know when you're free. | 09:59.39 |
| cryptopsy | 1mSYNOPSIS0m | 09:59.39 |
| ghostgum | kens: what sort of handles? | 09:59.40 |
| cryptopsy | with 1m-l22m, print the author of each file | 09:59.56 |
| chrisl | cryptopsy: going to ascii, thre is always that risk | 09:59.58 |
| kens | ghost: gum probably file handles. | 10:00.05 |
| cryptopsy | chrisl: no ... groff -Tascii doesn't have this problem | 10:00.13 |
| kens | Doh! ghostgum probably file handles | 10:00.19 |
| ghostgum | In Windows there are handles for this, and handles for that, and occasionally you use file handles. | 10:00.53 |
| kens | ghostgum : I know. At the moment its just a list of 'handles'. No idea waht kind right now. | 10:01.21 |
| ghostgum | I most commonly have problems with printer handles. | 10:01.29 |
| kens | Not likely here. This is just looking at the Process Explorere display. | 10:01.51 |
| cryptopsy | why is it so difficult to maintain indentation when going to text file, but easy when going from to pdf? | 10:02.19 |
| kens | ghostgum Using the API, simply starting and stopping GS uses 2 handles on the first occasion, and then 1 handle every invocation thereafter, which are never released. | 10:02.36 |
| | Actually, I would think GSView would experience this tooo. | 10:02.53 |
| ghostgum | Have you tried "nroff -man filename_of_man_page" | 10:03.02 |
| kens | cryptopsy : PS/PDF doesn't have 'indentation' it places text precisely on the page. | 10:03.21 |
| cryptopsy | does nroff? | 10:03.39 |
| kens | When going from 'x y moveto' back to ASCII you need to figure out how many spaces are requured. | 10:03.40 |
| ghostgum | kens: yes, leave GSview open and use it open then close 100 files and you used to find that memory usage kept growing. I haven't tested this recently. | 10:03.54 |
| cryptopsy | i think indentation in man pages is encoded in spaces not in positions | 10:04.17 |
| kens | Hmm, this isn't memory, its specifically handles, though I don't kow what type yet. | 10:04.18 |
| | cryptopsy send me a small exampe and I'll see what txtwrite makes of it. | 10:04.46 |
| ghostgum | kens: is txtwrite a PS/PDF to text converter? | 10:05.08 |
| cryptopsy | man -t man > file.ps |gs -sDEVICE=txtwrite | 10:05.21 |
| kens | ghostgum : its an 'anything GhostPDL handles' to text converter. | 10:05.55 |
| | Text = UTF-16 here. | 10:06.03 |
| | cryptopsy : I'm not running Linux, I need a file | 10:06.12 |
| ghostgum | good. Can it give page coordinates to words like pstotext? | 10:06.25 |
| cryptopsy | okay i'll upload the ps file for a man pagae | 10:06.33 |
| kens | ghostbot : In one format, yes. | 10:06.34 |
| | ghostgum : In one format of output, yes it does. | 10:06.46 |
| ghostgum | Good. I might be able to use it instead of the old pstotext. | 10:07.18 |
| kens | Amongst other things, like the font, point size, writing mode, render mode.... | 10:07.18 |
| cryptopsy | ratpoison.gs: PostScript document text conforming DSC level 3.0 | 10:07.21 |
| kens | cryptopsy : ? | 10:07.38 |
| cryptopsy | http://ompldr.org/vOW1kZw/ratpoison.gs | 10:07.42 |
| kens | got it, give me a moment | 10:07.59 |
| cryptopsy | the pdf ps2pdf produces is fantastic | 10:09.20 |
| kens | Its a different problem though. | 10:09.30 |
| | Drat, my debug binary doesn't work, I wonder why not. | 10:09.42 |
| cryptopsy | the ps required for that pdf to be built must be perfectly correct | 10:09.55 |
| kens | Yes, but like I said, its a different problem | 10:10.19 |
| cryptopsy | so why is it such a big problem for troff or groff to produce a text file | 10:10.20 |
| kens | Try reading the PostScript.... | 10:10.43 |
| cryptopsy | i understood it's a different problem for ps/pdf but this is before that | 10:10.49 |
| kens | Ah, now that I can't answer, I know zero about those applications.... | 10:11.07 |
| | Looks like one file handle is caused by opening the DLL :-) Naturally that isn't released until the application closes. | 10:12.07 |
| | cryptopsy : the output from txtwrite looks OK. | 10:13.03 |
| | If you have an email address I can sned it to you. | 10:13.13 |
| ghostgum | cryptospy: have you tried "nroff -man man.1" yet? | 10:13.48 |
| cryptopsy | could you upload it to ompldr.org ? | 10:13.49 |
| kens | Actually I see that its collapsing omse pieces of text together. | 10:13.49 |
| cryptopsy | or cryptopsy@live.com | 10:13.55 |
| kens | cryptopsy : I'll upload it if I can figure out how. | 10:14.06 |
| ghostgum | If you are trying to convert a man page to a text file, than that does it. | 10:14.14 |
| cryptopsy | just click 'ompload', or use curl | 10:14.22 |
| | ghostgum: i think so | 10:14.37 |
| ghostgum | Did that give something close to the desired output? | 10:15.04 |
| kens | http://ompldr.org/vOW1kbQ/out.txt | 10:15.07 |
| cryptopsy | the problem is usually missing indendation or partial unrendering of symbols | 10:15.20 |
| ghostgum | symbols? It's an ASCII file. What are symbols? :-) | 10:16.05 |
| cryptopsy | kens: full of @.^@^M^@ symbols | 10:16.05 |
| kens | Not for me, it is UTF16. | 10:16.21 |
| | Not ASCII | 10:16.28 |
| cryptopsy | ghostgum: like 1mSYNOPSIS0m | 10:16.30 |
| | i don't have utf16 support, but that's okay | 10:17.07 |
| chrisl | cryptopsy: is there a man page that's good example of the problems you see? | 10:17.20 |
| cryptopsy | all of them | 10:17.32 |
| | we can use man's man page for practice | 10:17.42 |
| kens | cryptopsy : http://ompldr.org/vOW1kbg/ratpoison.zip | 10:20.04 |
| | Same text file, but zipped in case it got corrupted in upload. I suspect its just because of UTF-16 though | 10:20.29 |
| cryptopsy | i can't tell the difference ... have no unicode support | 10:20.39 |
| kens | Hmm, well you coul delete all the 0x00 bytes :-) | 10:21.03 |
| cryptopsy | ... but my web browser does | 10:21.05 |
| kens | boggles at opening a txt file with a web browser. | 10:21.25 |
| cryptopsy | looks correct | 10:21.27 |
| kens | Its isn't reall :-) | 10:21.34 |
| | really | 10:21.37 |
| | Some of the words have run togehter | 10:21.44 |
| | Under DESCRIPTION fnacygraphics should be two words I think.... | 10:22.10 |
| chrisl | cryptopsy: what about using man2html and then lynx to dump the contents in ASCII? | 10:22.21 |
| cryptopsy | man2html has problems with indentation i think | 10:22.35 |
| | perhaps not, i don't remember | 10:23.35 |
| chrisl | The man manpage looks okay to me, but I'm not counting every whitespace character to find out! | 10:24.08 |
| cryptopsy | kens: in the original man page they are separate words | 10:24.11 |
| | damn bitch ass troff and groff | 10:24.49 |
| | what a waste of time | 10:24.58 |
| chrisl | cryptopsy: have you considered what you're trying to do might simply not be possible in the general case? | 10:25.07 |
| cryptopsy | sure | 10:25.15 |
| ghostgum | When I run "nroff -man zip.1 > zip.txt", I get a text file with indents using spaces, but lots of underlines and backspaces. | 10:25.16 |
| kens | cryptopsy : Exactly the problem. The code tries to decide if two closely spaced pieces of text are actually one word with text spacing, two words separated by a space, or two words in (for example) different columns. Its obviously too keen to merge words in this case. | 10:25.22 |
| ghostgum | To remove these, I open it in vi and do :s/.^H//g | 10:25.31 |
| kens | Not surprising since this is alpha release code | 10:25.40 |
| ghostgum | You could do this with sed from the command line. | 10:26.05 |
| cryptopsy | is zip.1 an actually file or do you just give the man page, append .1 and man somehow finds the file called man.1 ? | 10:26.06 |
| ghostgum | zip.1 is actually the uncompressed version of /usr/share/man/man1/zip.1.gz | 10:26.40 |
| ghostgum | remembers when formatting man pages took so long that catman was used and formatted pages were cached. | 10:28.42 |
| cryptopsy | i wasn't able to get man to pipe cat pages | 10:29.20 |
| ghostgum | liked the Unix man page for catman - it said something about acting strangely on a blue moon. | 10:29.37 |
| cryptopsy | i wonder how die.net does it | 10:30.28 |
| chrisl | cryptopsy: die.net has them in html doesn't it? | 10:31.32 |
| cryptopsy | i think so | 10:32.35 |
| chrisl | So, not simple ASCII text, then..... | 10:33.04 |
| malc_ | ~$ zcat /usr/man/man1/man.1.gz | mandoc | 10:34.01 |
| | man(1) man(1) | 10:34.01 |
| | NAME | 10:34.04 |
| tor8 | ghostgum: the "col" program mentioned by chrisl earlier strips out the backspace formatting | 10:34.15 |
| malc_ | oh well | 10:34.15 |
| cryptopsy | what are those 1m characters that col isn't processing | 10:41.16 |
| | ? | 10:41.17 |
| chrisl | cryptopsy: what about: "man -E ascii man | col -bx > man.txt" ? | 10:45.15 |
| kens | ping Robin_Watts | 11:05.36 |
| Robin_Watts | pong kens | 11:05.53 |
| kens | Hmm, now why did that come out underlined in Miranda ? | 11:05.55 |
| | Robin_Watts : So how can I look at this opdfread problem ? | 11:06.10 |
| Robin_Watts | in chatzilla too. | 11:06.11 |
| | just a tick. | 11:06.19 |
| | http://ghostscript.com/~robin/0001-mkromfs.patch | 11:07.35 |
| | download that, do: git am 0001-mkromfs.patch | 11:08.10 |
| | then rebuild. | 11:08.14 |
| kens | Working on it | 11:08.16 |
| Robin_Watts | Ta. | 11:08.19 |
| kens | clean build required ? | 11:08.59 |
| Robin_Watts | don't think so. | 11:09.20 |
| kens | find out in a minute :-) | 11:09.35 |
| | OK, so it built gsromfs | 11:10.17 |
| | now what ? | 11:10.34 |
| Robin_Watts | Now try any ps2write command. | 11:10.42 |
| kens | OK. | 11:10.49 |
| | Hmm, undefined filename | 11:11.30 |
| | Its trying to read one of the encoding files. | 11:11.52 |
| | gs_mgl_e.ps by the look of it. | 11:12.02 |
| | Maybe. | 11:12.29 |
| Robin_Watts | That's a different error than I was getting, I think. | 11:13.44 |
| kens | You didn't get an undefined filename ? | 11:13.55 |
| | Oh wait, there's an earlier error about library file not found | 11:14.26 |
| | Claiming to need opdfread.ps | 11:14.35 |
| Robin_Watts | That's the one. | 11:14.40 |
| kens | Hmm, looks like that comes (bizarrely) from gs_pdfwr.ps | 11:15.02 |
| | Which is executed at startup | 11:15.12 |
| Robin_Watts | Right. | 11:15.15 |
| | At this point I was into a maze of twisty ps, none of which I really understood, hence I thought I'd ask you. | 11:15.39 |
| kens | OK, leave it with me for a bit. It needs some of those files I think, but not all of them. Unless I've finally managed to remove them all and make them into C files ;-) | 11:16.20 |
| | Ah, the error is lying. | 11:16.57 |
| | It claims its looking for opdfread.ps but it isn't. Its looking for gs_agl.ps I think. | 11:17.35 |
| | I'll look more closely after lunch | 11:17.52 |
| Robin_Watts | Thanks. | 11:17.57 |
| | gs_agl.ps isn't in rom anymore. | 11:18.26 |
| kens | I have already removed that file and made it a C file :-) | 11:18.30 |
| | So it should have been removed fro there already anyway | 11:18.45 |
| | Its also one that needs to be merged with the txtwrite AGL file. | 11:19.00 |
| | Right now we have 2 copies of the data. | 11:19.09 |
| | In 2 different conflicting formats | 11:19.17 |
| Robin_Watts | gs_pdfwr.ps seems to mention gs_agl.ps | 11:19.33 |
| kens | Hmm, well it can stop that if it does :-) | 11:19.51 |
| | Its only used once, for ps2write, and its what's causing your erro (I htin). | 11:20.16 |
| | OK alll those PostScritp files are now in C header files. I should simply remove them from gs_pdfwr.ps. Its only checking for their presence, and that is no longer a potential error. | 11:21.20 |
| Robin_Watts | Right, cool. | 11:22.52 |
| kens | Robin_Watts : I'm going to grab some lunch. You can try a quick test if you like. The section marked "% Set a path to library files" Down to "} if" Just remove it and try that. | 11:23.00 |
| Robin_Watts | I have the code in pieces around me at the moment. | 11:23.13 |
| kens | OK, so I'll try it after lunch. | 11:23.22 |
| Robin_Watts | am rejigging it to do binary stuff. Thanks. | 11:23.26 |
| | Unrecoverable error: syntaxerror in binary token, type=142 | 12:15.49 |
| | What sort of syntax error can I have made in a stream of unencoded bytes? :) | 12:16.08 |
| kens | Presumably they are being executed somewhere | 12:16.26 |
| Robin_Watts | 142 is a token for a string. | 12:16.59 |
| kens | No string open mark ? I confess I don't know, binary sequences and tokens are rarely sued. | 12:17.32 |
| Robin_Watts | Byte 142 means: short string. | 12:18.05 |
| | next byte = number of chars (0 to 255) | 12:18.11 |
| | then followed by that many bytes of string data. | 12:18.20 |
| | No terminator. | 12:18.24 |
| kens | Pass then.... | 12:18.44 |
| Robin_Watts | Oh, I see what I've done. Fool! | 12:18.58 |
| kens | Robin_Watts : that seems to fix your problem, and a cluster push is OK. | 12:34.16 |
| Robin_Watts | kens: excellent. There's no downside to you committing that, right? | 12:34.39 |
| kens | No, but I'd liek to do it properly and remove all vestiges of OPDFReadProcsetPath | 12:35.12 |
| Robin_Watts | OK. | 12:35.28 |
| | I don't have a clue what any of that meant, so clearly me leaving it to you is the right thing to do ;) | 12:35.46 |
| kens | Hmm, I'm getting a lot of changes, I guess I need to do this again | 12:35.48 |
| | No problem, I'll do it (and cehck it) this afternoon. | 12:36.11 |
| | <sigh> Customer complaint :-( | 12:36.32 |
| | I'll leave it for Marcos :-) | 12:36.47 |
| | BTW I'm getting some warnings in gcc with your mkromfs changes | 12:39.21 |
| Robin_Watts | Thanks. I probably have tidying up to do. | 12:39.50 |
| | The version I have here is now radically different. | 12:39.59 |
| kens | Yes, I expect they are benign, just wanted you to know | 12:40.05 |
| | Well, I plan to revert to master, cluster test, remove all the OPDFread ProcsetPath stuff and test again | 12:40.34 |
| Robin_Watts | fab. | 12:40.46 |
| | git reset --hard HEAD~1 is the easiest way to remove a git am applied patch. | 12:41.10 |
| kens | Thanks, I was just going to do reset --hard.... | 12:41.24 |
| Robin_Watts | but be aware it will throw away any other changes you may have had in there! | 12:41.25 |
| kens | I have no other changes right now, but thanks for the warning | 12:41.38 |
| | I see the user in #692363 has managed to apply some sense.... | 13:27.33 |
| henrys | kens:great to see the text write device commit ! | 15:26.25 |
| kens | henrys its the basic working version. I expect *lots* of bugs and complaints. | 15:28.33 |
| | But I was keen to get 'seomthing' into the release. | 15:28.52 |
| | Robin_Watts : that last commit should solve your problems with ps2write. | 15:29.08 |
| Robin_Watts | kens: Fab, thanks. | 15:29.17 |
| kens | Morning ray_laptop | 15:30.14 |
| henrys | kens:so you don't want to replace ps2ascii yet | 15:31.04 |
| | ? | 15:31.05 |
| kens | Robin_Watts : I remember now why I hadn't done it before. The strings were garbage collected pointers and I couldn't figure out how to remove them without crashing the GC. | 15:31.13 |
| | henrys I think we should leave ps2ascii for trhis release. | 15:31.28 |
| Robin_Watts | kens: Ah. And now you have? | 15:31.30 |
| kens | Robin_Watts : Yes, it wasn't hard, but I think I was pressed for time last time around. | 15:31.47 |
| | henrys I really do expect people will complain and find genuine bugs with this implementation. | 15:32.08 |
| Robin_Watts | Well, I'm clusterpushing the revised mkromfs + your changes now. | 15:32.15 |
| kens | I already cluster pushed just my stuff and it was OK> The commit is being tested now. | 15:32.36 |
| | henrys I sent some words to chris for the release notes asking people not to submit bugs and feature requests to Bugzilla, but to send them to gs-devel instead. | 15:33.06 |
| | If I like them then I'll add them to Bugzilla, but I don't want to get swamped in bugs for it. | 15:33.28 |
| | fetching coffe, brb | 15:35.56 |
| Robin_Watts | kens: The purpose of the test is no so much for your changes, but for mine :) | 15:36.56 |
| kens | Yes, I assume dhtat, just mentioning that they were OK alone :-) | 15:38.02 |
| kens | is over warm for the first time in weeks. | 15:38.18 |
| ray_laptop | Robin_Watts: with your changes is the -g and -C modes the default ? | 15:38.57 |
| | kens: is there a reason you didn't generate UTF-8 ? | 15:39.50 |
| kens | UTF-16 is easier :-) | 15:40.06 |
| | Its what falls out of the ToUnicode CMaps and stuff | 15:40.36 |
| Robin_Watts | ray_laptop: The changes in the makefile in the test use -g and -C, yes. | 15:41.48 |
| | I haven't committed anything yet. | 15:41.56 |
| | I have the binary encoding stuff working; gets the rom down to 6.81 Meg. | 15:42.28 |
| | from 7.8x Meg. | 15:42.54 |
| | I cocked up a moment ago, and optimised everything away, and ended up with 3.8x Meg. | 15:43.35 |
| kens | Excellent compression, but probably non-functional.... | 15:44.00 |
| ray_laptop | optimized everything away and you still had 3.8 M ??? | 15:44.09 |
| Robin_Watts | so there is 3.8Meg of stuff in the rom that the compaction stuff isn't being applied to (icc profiles, etc) | 15:44.13 |
| | yes. | 15:44.15 |
| kens | ray_laptop : I've passed a problem with handles to you this morning, but I'm not sure if it belongs to you. Feel free to hand it back if not. | 15:44.41 |
| ray_laptop | Robin_Watts: that's probably mostly the Fonts | 15:45.32 |
| Robin_Watts | ray_laptop: Right. It was an unintentional mistake, but it gave an informative figure :) | 15:45.52 |
| kens | henrys, chrisl, bug #692372, do you think this should be a release blocker ? I think not, because it has existed previously. | 15:46.10 |
| ray_laptop | Fonts don't compress all that well (might be better if someone converts them to CFF) | 15:46.18 |
| kens | CFF conversion is easy, as Alex says. | 15:46.32 |
| | But it doesn't generally save very much over type 1. We did it for Jaws though. | 15:46.51 |
| | In fact Jaws converted all type 1 fonts into CFF itnernally to save memory. | 15:47.04 |
| | type 1 CharStrings I should probably say. | 15:47.38 |
| chrisl | kens: except incremental type 1 fonts....... | 15:47.40 |
| kens | Yes, because incremental ones can change ;-) | 15:47.52 |
| | I think it could probably be done though. | 15:48.06 |
| chrisl | I thought you couldn't incremental type 2 fonts | 15:48.42 |
| kens | You can't, but you can convert the CharStrings from type 1 to type 2 and tehn treat them like a type 1 font, but with type 2 charstrings. | 15:49.12 |
| henrys | kens:probably not a blocker but certainly high priority, ray_laptop will you have time to look at 692372 soon before the release? | 15:49.18 |
| Robin_Watts | ray_laptop: At the moment, the compaction isn't done on the init file. | 15:49.22 |
| | (or at least *my* compaction isn't done on the init file). | 15:49.57 |
| | I'm going to have a look at changing mkromfs to flatten with your code, then compact with mine) | 15:50.27 |
| chrisl | kens, henrys: I don't consider 692372 to be a blocker - it's not new, it's not a very common usage, and (AIUI) you'd have to do restart GS a lot before it affected functionality (correct me if I'm wrong). | 15:50.38 |
| kens | sees chrisl has created the release branch, so not a blocker then :-) | 15:50.44 |
| chrisl | kens: it can still be a blocker, it just means I'd need to pull in the fix for it. | 15:51.04 |
| ray_laptop | kens: henrys: the gsicc_cache_new is allocating BOTH a monitor and a semaphore (each of which probably uses a handle) and then freeing them the wrong way | 15:51.12 |
| kens | ray_laptop : It only leaks one handle there, unless the second one is allocated during interpretation. | 15:51.47 |
| ray_laptop | it looks like a VERY easy fix | 15:51.49 |
| Robin_Watts | sags pointed out a potential problem with the unicode/utf8 stuff last night. | 15:52.09 |
| kens | It leaks 2 handles per run, but I have no idea how many a Windows application is allowed these days. | 15:52.11 |
| Robin_Watts | 10000, says Mr Google. | 15:52.40 |
| ray_laptop | kens: it should create two handles there (one for each) | 15:53.01 |
| Robin_Watts | 10000 per process, 32K in the entire system. | 15:53.01 |
| kens | So 5,000 jobs without a restart, unless a real job leaks even more handles, which is possible. | 15:53.06 |
| | My test case just started up GS and exited. | 15:53.21 |
| | ray_laptop : it only seems to create one. | 15:53.45 |
| | After executing the gs_semaphore (or whatever the routine is called) the handle count goes up by one. | 15:54.08 |
| ray_laptop | well, the 'free' of both is wrong. I'll fix that at least | 15:54.09 |
| kens | ray_laptop : if you send me the code fix I can check it here. I have the customer app all set up already | 15:54.34 |
| | Robin_Watts : My opdfread commit just passed msuter from the regular cluster tests as well, so I'm pretty happy with it. | 15:56.01 |
| ray_laptop | kens: OK. I'm going to check the other ICC code for the same mistake, then I'll rebuild and smoke test, then send you the patch. | 15:57.29 |
| kens | Sounds good to me. | 15:57.39 |
| ray_laptop | kens: sure enough, gsicc_link_free had the same mistake. | 15:59.41 |
| kens | Well, maybe that's teh second handle.... | 15:59.53 |
| cryptopsy | chrisl: i don't have a -E option for man | 16:00.21 |
| chrisl | cryptopsy: hmm, what platform are you running on? | 16:02.34 |
| cryptopsy | linux | 16:02.39 |
| | x86_64 | 16:02.48 |
| chrisl | Same as me, then - strange...... | 16:03.03 |
| cryptopsy | what does -E do? | 16:03.15 |
| chrisl | Sets the encoding for the text output. What about --encoding=ascii ? | 16:03.54 |
| cryptopsy | the word encoding doesn't appear in my man manpage | 16:06.37 |
| henrys | chrisl:great getting the branch split off early. | 16:06.44 |
| chrisl | henrys: actually a little late - remember we're aiming to release *early* in August this time...... eek! | 16:07.21 |
| henrys | is anything due for tkamppeter ubuntu release? | 16:08.17 |
| | chrisl? | 16:08.24 |
| chrisl | henrys: he raised some crashes with Robin_Watts, I don't where that went. I don't know if they were blockers either. | 16:09.10 |
| Robin_Watts | he has reported some SEGVs, but nothing that is a blocker. | 16:09.18 |
| | One is assigned to alex, the other is unassigned, but I was planning to have a quick look at it tomorrow. | 16:09.38 |
| | (unless anyone gets there first) | 16:09.51 |
| kens | I could look tomorrow if required. | 16:10.06 |
| henrys | kens:I think we should at least have another script maybe ps2text or something so it gets used. What do you think? | 16:10.06 |
| kens | henrys we could do that, but we'd need ps2text, pdf2text and presumably pcl2text and xps2text as well ;-) | 16:10.38 |
| | Also, its not strictly 'text' because most people will think ASCII and its actually Unicode output. | 16:11.01 |
| Robin_Watts | The profileration of scripts seems like a bad thing to me. | 16:11.19 |
| kens | We could do an ASCII version too. | 16:11.20 |
| ray_laptop | kens: here's the patch, let me know. I'll commit it in either case, but may change the message if it is only a partial fix: http://ghostscript.com/~ray/patches/0001-Fix-freeing-of-monitor-and-semaphores-for-ICC-cache..patch | 16:11.27 |
| kens | I'm with Robin, I'd prefer people learned to use the devices. | 16:11.40 |
| | ray_laptop : getting it now. | 16:11.48 |
| henrys | kens:okay. | 16:12.01 |
| ray_laptop | IMHO, if we do scripts they shouldn't be ___2text if we are doing UTF-16 -- lots of bug reports if we did that | 16:14.36 |
| | but I think that is what ken said as well. | 16:14.59 |
| kens | :-) | 16:15.07 |
| henrys | yes 2unicode is fine, I really don't think it will get on open source radar without scripts but we'll see. | 16:15.59 |
| ray_laptop | I do think we should have an UTF-8 output mode, maybe with that as default as it will produce ASCII for the 'common case' (i.e. us english speakers) | 16:16.09 |
| kens | We could do that too. THis is the sort of thing I want feedback on, but didn't want before the basics were working ;-) | 16:16.34 |
| ray_laptop | kens: np. I'm glad it's finally getting close enough to (sort of) work. | 16:17.26 |
| kens | Some files shuld work well, (especially simple ones) others less well. The Adobe Type manager 4.2 flyer works quite well, as does Tor's 'captions.pdf' file. | 16:18.12 |
| | The man page this morning worked OK, but was over-enthusiastic about mergin adjacent text. | 16:18.30 |
| | So that heuristic needs tweakiong or thinking about. | 16:18.44 |
| ray_laptop | so running gs lots of times on windows might be why my performance sometimes gets really piggy until I reboot (getting low on handles) ??? I didn't know there were still limits -- I recall from Win 95 days seeing "system low on resources" which were usually handles. | 16:20.00 |
| kens | In those days i think the limit was a few tens of handles. | 16:20.27 |
| ray_laptop | and I don't quite understand why the system doesn't reclaim handles when gs exits | 16:20.34 |
| kens | ray_laptop : I'm not seeing any improvement. Still seems to leak 2 handles. I'm goign to do a clean bbuild. | 16:20.53 |
| | ray_laptop : it does reclaim the handles I think. The customer is using GS in a DLL, so the process doesn't exit. | 16:21.20 |
| ray_laptop | kens: I see. | 16:21.38 |
| | kens: are you running the 'loop' as well, or just looking at a single run ? | 16:22.24 |
| kens | Both. | 16:22.32 |
| | That is I'm running the loop, but looking at a single iteration of the loop | 16:22.50 |
| | Hmm I see. THe DLL is new, but the .lib is not. That's bad. | 16:23.49 |
| ray_laptop | kens: how do you see the handles ? VS debugger or the thingy from the bug report | 16:23.52 |
| kens | ray_laptop : I'm using Process Explorer, its a nice tool | 16:24.07 |
| | Had it in various versions for years | 16:24.14 |
| ray_laptop | kens: oK. thanks. | 16:24.18 |
| kens | Just starting a clean build of GS to see if I get a proper .lib file this time. | 16:24.48 |
| ray_laptop | kens: are you building the big lib (msvclib.mak) or just the one built by default ? | 16:25.34 |
| kens | Everything :-) | 16:25.44 |
| | It must have been a glitch, it worked fine this morning. | 16:26.15 |
| | i7 appears to have died. | 16:27.33 |
| ray_laptop | kens: was your comment "It must have been a glitch, it worked fine" about my patch or something else ? | 16:33.18 |
| kens | THe fact that I couldn't debug into the DLL. I staill can't and I have no idea whay. | 16:33.36 |
| henrys | tor8:we need some sort of response on 692354 | 16:33.49 |
| kens | Without that I can't easily see where the handles are being allocted | 16:33.51 |
| | But I'm still seeing an increase of 2 handles per loop iteration. | 16:34.06 |
| | AH, I htink I see. | 16:34.29 |
| tor8 | henrys: I've been looking into it, I think we need to do something with robin's image scaling code | 16:34.59 |
| Robin_Watts | tor8: If it's scaling, assign it to me, and I'll look at that tomorrow, instead of tkamppeters SEGVs. | 16:36.07 |
| kens | OK, now I'm using the right code.... | 16:37.10 |
| tor8 | Robin_Watts: I think we need to disable the sub pixel offsets when scaling for non-type3 images | 16:37.11 |
| | so we get grid aligned images without transparent edges | 16:37.27 |
| henrys | tor8:it is a mupdf customer! | 16:37.28 |
| Robin_Watts | henrys: ? | 16:37.53 |
| | I wrote mupdfs bitmap scaling code. | 16:38.21 |
| kens | ray_laptop : definitely not seeming to release handles. | 16:38.29 |
| tor8 | need to pop out for a bit, be back in an hour or so | 16:38.52 |
| kens | ray_laptop : if anything, in fact, its worse. | 16:39.15 |
| | Seems to be leaking 3 handles now instead of 2. | 16:39.24 |
| | I'll look some more tomorrow | 16:39.54 |
| | Off now, goodnight everyone. | 16:40.04 |
| tkamppeter | henrys, Robin_Watts, I have some more bugs: http://bugs.ghostscript.com/show_bug.cgi?id=692233, http://bugs.ghostscript.com/show_bug.cgi?id=692042, http://bugs.ghostscript.com/show_bug.cgi?id=691922, http://bugs.ghostscript.com/show_bug.cgi?id=690435, http://bugs.ghostscript.com/show_bug.cgi?id=689957 | 16:59.37 |
| | henrys, Robin_Watts, the first two are probably the most important of them. | 17:00.01 |
| henrys | Robin_Watts:I'm back | 17:00.28 |
| Robin_Watts | henrys: ok... | 17:00.47 |
| tkamppeter | henrys, see also my last two messages ^^ | 17:01.01 |
| henrys | tor8, Robin_Watts:point is a customer bug shouldn't sit with no response beyond the original report | 17:01.15 |
| Robin_Watts | right. I'd not seen it before. | 17:01.28 |
| | but I'll get right on it. | 17:01.43 |
| henrys | well no it wasn't assigned to you. | 17:01.59 |
| | so 692233 runs okay without the ppd? | 17:03.40 |
| | tkamppeter? | 17:04.22 |
| | tkamppeter:and I thought mvrhel2 just fixed 692042? | 17:05.55 |
| tkamppeter | henrys, he did not mark it as such. Bug is still open with last comment back in April. | 17:12.54 |
| | mvrhel2, hi | 17:14.15 |
| mvrhel2 | hi tkamppeter | 17:14.27 |
| tkamppeter | mvrhel2, henrys tells that you have fixed bug 692042 but it is not marked as such. | 17:14.47 |
| mvrhel2 | oh. this was not assigned to me | 17:15.23 |
| | that is why I did not find it | 17:15.32 |
| henrys | tkamppeter:the bugs is assigned to you why? | 17:15.38 |
| mvrhel2 | yes that is fixed | 17:15.43 |
| | I will closed it as fixed to the appropriate commit | 17:16.05 |
| henrys | all of them seem to be assigned to you. | 17:16.07 |
| | tkamppeter | 17:16.17 |
| | tkamppeter:you should not assume we'll look at bugs that are not assigned. Do you need help assigning these? | 17:17.11 |
| mvrhel2 | I usually filter bugzilla to see only my bugs | 17:17.12 |
| tkamppeter | tkamppeter, I do not know why mvrhel2 did not change the assignee to himself when he fixed that bug. | 17:17.20 |
| mvrhel2 | huh? | 17:17.50 |
| tkamppeter | tkamppeter, at least I close bugs when I fix them also if the assignee is someone else. | 17:17.53 |
| henrys | I'm confused. | 17:17.57 |
| mvrhel2 | me too | 17:18.05 |
| Robin_Watts | tkamppeter: I think the issue is that mvrhel2 was not aware of the bug. | 17:18.40 |
| mvrhel2 | exactly | 17:18.46 |
| henrys | tkamppeter:you need to assign the bugs to someone or assign them to support or they will not be looked at. | 17:18.58 |
| Robin_Watts | It happened to get fixed as part of something he did, but it wasn't specifically in response that that report. | 17:18.59 |
| tkamppeter | henrys, the help I need in assigning is assigning the bugs to the right person. So please tell me to whom to assign the still open bugs. | 17:19.08 |
| mvrhel2 | There was a customer bug that was basically a duplicate of this bug | 17:19.52 |
| | which I fixed and closed | 17:19.57 |
| henrys | tkamppeter:I should have been more clear michael fixed a problem for a customer that I realized should fix your bug also. | 17:19.58 |
| | tkamppeter:just push them to support@artifex.com - if you can assign to a component like color, fonts it will get a default assignment. | 17:21.21 |
| tkamppeter | Bug http://bugs.ghostscript.com/show_bug.cgi?id=690435 seems to be fixed, but with some guesswork. All examples in the bug work with the 9.04 snapshot. So I will close it. | 17:23.58 |
| mvrhel2 | alexcher are you there? | 17:29.50 |
| ray_laptop | so Robin_Watts' CMap coding reduces the compressed CMaps by 501,959 (uncompressed reduced by 3,700,264). The initfiles (mostly the -g change) went down by 213,206. A few more K in encoding, colorspace and decoding | 17:30.45 |
| Robin_Watts | ray_laptop: Which version of mkromfs are you looking at ? | 17:31.23 |
| tkamppeter | mvrhel2, you should have received two bugs with color problems now. | 17:31.30 |
| mvrhel2 | tkamppeter: ok | 17:31.41 |
| ray_laptop | Robin_Watts: origin/master vs. the patch you posted. | 17:32.15 |
| Robin_Watts | right. | 17:32.25 |
| | todays version should do better. | 17:32.36 |
| | but when I just tested it on the cluster I had lots of problems. | 17:32.57 |
| ray_laptop | Robin_Watts: I thought that was today's (the patch you posted for ken here in IRC logs) | 17:33.16 |
| Robin_Watts | ray_laptop: No, that was yesterdays. It ran clean on the cluster except for ps2 problems, and kens fixed those. | 17:33.51 |
| ray_laptop | Robin_Watts: I took it from ~robin/0001-mkromfs.patch | 17:33.54 |
| mvrhel2 | henrys: I am going to push bug 692105 to alex. When I run the pdf file I get a complaint from the interpreter. When I include the -dPDFSTOPONERROR that alex suggested I get a limitcheck error. Not sure what is going on there but it I don't think it is a color issue | 17:33.56 |
| Robin_Watts | So that *should* run clean now. | 17:34.06 |
| henrys | mvrhel2:sure | 17:34.25 |
| Robin_Watts | The version I am working on locally gets better compaction by using the binary stuff, but is currently broken. I'm debugging now. | 17:34.35 |
| henrys | mvrhel2:what do you think of the patch on 692329 is that going to work similarly to the old code. Presumably those colors will now be converted but I wonder if that will be okay. | 17:35.25 |
| | s/old code/old code?/ | 17:35.43 |
| mvrhel2 | hold on | 17:36.52 |
| ray_laptop | Robin_Watts: the current fonts (3,356,998) currently only compress by 36,462 bytes, but my previous experience with fonts without eexec (like today's CFF) we were able to get about 30% compression. Another Mb would be worth the try. | 17:38.52 |
| | of course, we were using bwbs compression at the time | 17:39.27 |
| Robin_Watts | ray_laptop: I don't follow that. | 17:39.41 |
| | "fonts without eexec"? You mean, changing the format of the fonts from Type1 to CFF? | 17:40.10 |
| mvrhel2 | henrys: that needs to be written a bit different | 17:40.40 |
| alexcher | mvrhel2: I'm back. | 17:41.46 |
| mvrhel2 | hold on | 17:41.48 |
| | alexcher. I am assigning you bug 692105 | 17:42.14 |
| tkamppeter | Who is the specialist for the build system under Linux (./configure; make; ...) at Ghostscript? | 17:43.42 |
| alexcher | mvrhel2: OK, I'll check what can be done about the function. | 17:43.47 |
| Robin_Watts | tkamppeter: build problems go to chrisl. | 17:44.04 |
| tkamppeter | OK, then he will get a bug now ... | 17:44.22 |
| mvrhel2 | alexcher: I did not understand you email about the function, nor could I "catch" it | 17:44.32 |
| | in the manner you suggested | 17:44.47 |
| | AR opens the file | 17:44.57 |
| | and it was generated by Acrobat distiller | 17:45.10 |
| | I would think we should be able to handle it | 17:45.20 |
| alexcher | mvrhel2: The limit on the number of dimensions in the interpolation table is too low in gs. | 17:45.39 |
| mvrhel2 | with at most a simple parameter limit change | 17:45.41 |
| | is it a simple parameter to change to increase? | 17:46.03 |
| alexcher | mvrhel2: We need to take into account the number of point along every dimension. | 17:46.27 |
| | mvrhel2: Iven better, such functions should be converted to a PS calculator function. | 17:47.04 |
| | Even | 17:47.17 |
| mvrhel2 | ok. well that sounds like a great project for you rather than me | 17:47.28 |
| | tkamppeter: which bugs did you assign to me? | 17:47.49 |
| tkamppeter | henrys, bug 692328 for you. | 17:48.58 |
| | mvrhel2, bug 689957 and bug 691922 | 17:50.02 |
| | mvrhel2, also bug 691952 is important for a color-managed print workflow. | 17:51.09 |
| mvrhel2 | So 689957 is work that needs to be dong in gdevcups.c | 17:52.11 |
| tkamppeter | henrys, bug 692329 is also important for printing and a proposed patch is attached. | 17:53.19 |
| mvrhel2 | 691922 probably requires some work on the encode and decode operations for cups | 17:53.35 |
| henrys | tkamppeter:right mvrhel2 says the patch needs work. | 17:54.23 |
| tkamppeter | mvrhel2, but I do not know how to fix 689957, especially no one of you answered my question in comment #18. | 17:54.45 |
| henrys | I also need marcos to add pxlmono and color to the overnight before I'm willing to make a change like that. | 17:55.21 |
| mvrhel2 | tkamppeter: I understand. Just taking a quick look at these | 17:55.38 |
| | since we can now do cups raster output on windoze, I should be able to figure these out | 17:56.39 |
| | within a reasonable amount of time | 17:56.44 |
| henrys | mvrhel2:if this is something shailesh can correct update the bug with your critique. (692329) | 17:56.59 |
| mvrhel2 | henrys: back to the patch | 17:57.05 |
| | yes. I will attach a comment on the bug | 17:57.55 |
| tkamppeter | mvrhel2, and for the encode and decode operations in the CUPS driver I need help from a color expert, like you ... | 17:58.27 |
| mvrhel2 | tkamppeter: yes I understand. I was just rambling a bit. I may try to take a precursor look at them this week if time permits | 17:59.35 |
| | uhoh | 17:59.58 |
| mvrhel2 | sees something he may have broke recently | 18:00.30 |
| | prompted by the patch... | 18:00.44 |
| Robin_Watts | henrys: sags raised an issue last night to do with gsapi and utf8. | 18:01.22 |
| mvrhel2 | henrys: let me do a fix for something, then I will let shailesh know what he needs to do | 18:01.31 |
| Robin_Watts | specifically he'd like unicode equivalent entrypoints. | 18:01.58 |
| mvrhel2 | ah false alarm whew | 18:02.57 |
| henrys | Robin_Watts:yes I saw the discussion - but I'm not quite sure I deeply understand the issue. | 18:03.18 |
| Robin_Watts | I'm not sure I deeply understand it either. | 18:03.39 |
| tkamppeter | I have also good news for you: Two users who complained about printing slowness tell that their problems got solved, after I have once updated to the newest GIT snapshot of 9.04 in Ubuntu and second, by adding "-dNOINTERPOLATE" to all GS command lines in printing-related packages in Ubuntu. | 18:04.02 |
| henrys | that's good we could probably disable a lot of other stuff and it would be really fast ;-) | 18:04.52 |
| Robin_Watts | Currently, the entrypoints take 8 bit characters in, and gs has always just treated any top bit set chars as themselves and passed them back out again. | 18:05.03 |
| | Now, we're assuming that the data coming in is in utf8 format. | 18:06.14 |
| | So people calling the entrypoints with top bit set chars might get confusing results. | 18:06.39 |
| henrys | but why is it different than linux or mac os x? | 18:07.13 |
| Robin_Watts | Do linux and macosx have gsapi? I guess they do, as part of a shared lib ? | 18:08.10 |
| henrys | which seems to be treating everything as utf8 withouth your change. | 18:08.15 |
| Robin_Watts | On linux and macosx, they've always been treating stuff as utf8. | 18:08.28 |
| | On windows we've changed to treat stuff as utf8, where previously we were treating it as ANSI. | 18:09.01 |
| | It's the change in behaviour that offends him, I believe. | 18:09.19 |
| henrys | I guess I would need to see examples of how the behavior does change in some "real world" setting before saying anything intelligent about it. | 18:12.23 |
| Robin_Watts | ok. | 18:12.43 |
| henrys | I'm inclined to ship with it. ray_laptop, chrisl_away should weigh in too. | 18:13.42 |
| | maybe I am missing something. | 18:13.50 |
| ray_laptop | as I understand it, it will change when the paths passed in as args (argv) | 18:13.53 |
| | if these come in via our 'front end' (gswin32 gswin32c) then we can handle it, but other clients that construct paths on CJK Windows might trip | 18:15.16 |
| henrys | so we announce a non backward compatible change and provide some documentation. | 18:16.20 |
| Robin_Watts | ray_laptop: Currently, there is *no* way that cjkv windows can use gsapi to call gs on paths with chars >= 256, AIUI. | 18:16.53 |
| | They can get away with calling gsapi on paths with chars >= 128 and <256. | 18:17.21 |
| | Under the new scheme, they can no longer safely pass paths in with chars >= 128 and <256. | 18:17.47 |
| ray_laptop | I don't know what we used to do, and am not knowledgeable about the windows calls that we used and used now. | 18:17.55 |
| henrys | so it isn't really cjk ... | 18:18.00 |
| | just the extended ascii that is possibly incompatible. | 18:18.34 |
| Robin_Watts | But the benefit they get is that they can now do the utf8 encoding themselves, and safely pass paths containing any values they want (effectively). | 18:18.41 |
| henrys | or different | 18:18.43 |
| Robin_Watts | henrys: indeed. | 18:18.46 |
| | AIUI. | 18:18.48 |
| henrys | voila not a bug it's a feature! | 18:19.17 |
| Robin_Watts | My view is, I think (and I reserve the right to change my mind with no notice) is that we should ship with unicode enabled on the grounds that we've pulled windows into line with macosx and linux. | 18:20.04 |
| ray_laptop | I know that some people used to pathname strings to gs as hex encoded, but that wasn't the argv method -- they'd send in PostScript with things strings inside < > | 18:20.05 |
| Robin_Watts | and if they don't like it, they can build with WINDOWS_NO_UNICODE. | 18:20.33 |
| ray_laptop | what about the european funky characters -- are they in the problem range ? | 18:20.34 |
| Robin_Watts | ray_laptop: Those are exactly the ones in extended ascii that might be a problem. | 18:20.52 |
| ray_laptop | things like the german umlauted chars and the letters with accents and slashes | 18:21.25 |
| Robin_Watts | yes. | 18:21.32 |
| ray_laptop | we have an awful lot of european customers and users | 18:21.49 |
| mvrhel2 | henrys: OK I posted a comment on how to fix the patch . | 18:22.28 |
| Robin_Watts | walks dogs. bbs. | 18:23.15 |
| ray_laptop | If it changes behavior for the european users, then I'd be a LOT more comfortable making NO_UNICODE the default. After all, it's not like we've had a clamor from Windows users asking for UTF-8 | 18:23.26 |
| mvrhel2 | oops I wonder about the CMYK case on that though | 18:24.47 |
| henrys | ray_laptop:it is not a big deal announcing and documenting a non backward compatible change. As it is not we have platform difference mac and linux are always uft8 | 18:27.52 |
| | s/is not/is now/ | 18:28.07 |
| mvrhel2 | bbiaw | 18:36.31 |
| tor8 | Robin_Watts: back | 18:43.58 |
| henrys | tkamppeter:that sed patch is fine for me if it works but you are the one set up to test it. | 18:51.15 |
| | that is 692328 | 18:52.00 |
| Robin_Watts | tor8: Possibly, for images that aren't type3s and aren't transparent, we should grid fit them, yes. | 19:09.05 |
| | but equally, we should perhaps seek to understand why the images aren't lining up exactly. | 19:16.29 |
| tor8 | robin_watts: even if they line up, the AA blending (50% over + 50% over = 75% final color) | 20:32.48 |
| | makes the white lines appear | 20:32.55 |
| Robin_Watts | tor8: ah, ok. | 20:33.04 |
| tor8 | which is why, for non-type3 largish images we could try doing grid fitted images | 20:33.48 |
| | another idea I had was to buffer in the interpreter, or post-process the display list, to merge adjoining images with the same width and colorspace | 20:34.20 |
| Robin_Watts | That would be ideal, but hard, I think. | 20:34.34 |
| tor8 | yeah, it'd work in 80% of cases and fail miserably for others, most likely | 20:34.52 |
| | not to mention make the memory usage worse | 20:35.17 |
| | seeing as reducing memory is probably the reason they were split to begin with | 20:35.35 |
| Robin_Watts | Rats. I thought I had the compaction stuff working for a mo, and then I realised tiger was in greyscale... | 20:56.25 |
| | Forward 1 day (to 2011/07/26)>>> | |
IRC Logs