| | <<<Back 1 day (to 2013/05/05) | 2013/05/06 |
| kens | chrisl ping | 09:13.05 |
| chrisl | kens: pong | 09:13.36 |
| kens | How are you on the font/matrix cache ? (fm_pair) | 09:13.54 |
| chrisl | I haven't looked at it much | 09:14.13 |
| kens | Ah, I was hoping you would know how fonts get flushed from it, if you don't then I'll carry on looking | 09:14.35 |
| chrisl | IIRC, they get flushed when the font object itself is destroyed (usually on a restore) | 09:15.18 |
| kens | That's the problem I'm seeing I think. THe fonts in the cache are copies held by pdfwrite. When we destroy them, the fm cache is still pointing to them. | 09:16.02 |
| | Of course this only happens with %d in the output filename (because otherwise we hodl fonts to the end of the job). | 09:16.37 |
| chrisl | Okay, I would think that the right thing to do would be to add a "notification" to the pdfwrite copy which explicitly removes the fm_pair when the font is destroyed | 09:17.18 |
| kens | I know when the font is destroyed, just trying to figure out how to remove it from the cache | 09:17.46 |
| chrisl | fm_pair_remove_from_list() ? | 09:18.38 |
| kens | BTW (bonus point) When we run the 'show' procedures, 'design_grid' is false, unless we are doing a charpath, when we get a TT outline, design_grid is always true.... | 09:18.39 |
| | chrisl could be, I guess I'd have to do fm_lookup_pair first | 09:19.00 |
| | gx_lookup_fm_pair that is | 09:19.15 |
| chrisl | Actually, maybe gs_purge_fm_pair() is the appropriate call | 09:20.51 |
| kens | Umm, maybe. I'm just looking for where I dereference the font at the moment.... | 09:21.15 |
| chrisl | Yes, gs_purge_fm_pair() - it removes the fm_pair from the "active" list, adds it to the "free" list. | 09:22.18 |
| kens | OK that sounds good, let me see if I can find out where the font is freed.... | 09:22.39 |
| chrisl | Well, like I say, you can add a notification to the font object so you don't need to worry about *where* it gets freed: "gs_notify_register()" | 09:24.41 |
| kens | Hmm, could be a good idea, I may already have one though | 09:25.03 |
| | Seems not | 09:25.36 |
| Robin_Watts | Morning all | 09:29.46 |
| kens | Morning | 09:29.51 |
| Robin_Watts | tor8: reworked rtl commit on robin/master | 09:56.55 |
| paulgardiner | Morning | 10:00.52 |
| Robin_Watts | morning paulgardiner - how goes windows RT hell? | 10:03.16 |
| paulgardiner | Well at least I can debug now, and I discovered there was an error returned -12, seems to be something going wrong in gs_run_init_file, although it does seem to be interpreting tokens from what I guess is a rom file | 10:04.54 |
| | Was just trying to find out what -12 means | 10:05.15 |
| Robin_Watts | #define gs_error_ioerror (-12) | 10:05.39 |
| | gs has an init file, that is compiled into the "rom filing system" | 10:06.28 |
| paulgardiner | Yeah, it looks to be opening it okay | 10:06.45 |
| Robin_Watts | (whether it is compiled in, or run from a file depends on COMPILE_INITS I think but it's on by default) | 10:07.00 |
| paulgardiner | So could the io error be something to do with stdout or stderr | 10:07.04 |
| Robin_Watts | paulgardiner: Could be. | 10:07.11 |
| | Try breaksetting "return error". | 10:07.27 |
| | "return_error" | 10:07.31 |
| | sorry, that's a macro | 10:07.47 |
| | gs_note_error | 10:07.51 |
| paulgardiner | Oh right. Will give that a try | 10:08.08 |
| Robin_Watts | Often errors are raised by doing: return_error(blah); so they can be trapped. | 10:08.20 |
| paulgardiner | Yeah handy | 10:09.47 |
| tor8 | Robin_Watts: pspan is not very well named | 10:21.16 |
| Robin_Watts | pointer to span ? | 10:36.42 |
| | pointer_to_current_span_on_previous_line | 10:37.19 |
| tor8 | prev_line_span? | 10:41.46 |
| Robin_Watts | that doesn't encapsulate the fact it's a pointer to a pointer. | 10:43.49 |
| tor8 | ..._p | 10:44.04 |
| | "pspan" adds no information content that can't be obtained by the type, and it's complicated enough to need some | 10:44.58 |
| paulgardiner | Strange it's dropping out with a syntax error because of running scan_number over ".quit". | 10:45.52 |
| Robin_Watts | tor8: I can change to prev_line_span. Anything else ? | 10:46.34 |
| paulgardiner | Robin_Watts: where in the directory tree does the init file live? Maybe I can spot what part of it the interpreter has run in to. | 10:47.29 |
| tor8 | Robin_Watts: nope, that's all | 10:48.09 |
| chrisl | paulgardiner: Resource/Init/gs_init.ps | 10:48.30 |
| paulgardiner | Ta. | 10:48.53 |
| Robin_Watts | paulgardiner: but it's run from inside a .h file, effectively. | 10:48.59 |
| | and it's compacted/compressed as part of the build process. | 10:49.11 |
| paulgardiner | Seeing as the whole thing fails with an io error, the syntax error may well be a red herring. | 10:49.40 |
| | The io error is from zwritecvp_at | 10:51.16 |
| Robin_Watts | 'z' means that's a postscript interpreter function. | 10:51.43 |
| chrisl | paulgardiner: it probably is a stdout problem, you're probably hitting the call to .writecvp that happens early in gs_init.ps | 10:55.00 |
| paulgardiner | That would figure. I think I'm close to tracing it to a sputc call | 10:56.06 |
| Arya_ | anyone online? | 10:56.39 |
| chrisl | Arya_: maybe - depends what you want..... ;-) | 10:57.42 |
| Arya_ | I have a query regarding GhostScript. Can i use GS to convert Doc files to PDF? | 10:58.43 |
| | If you could pls. point me to right direction. | 10:59.17 |
| chrisl | Arya_: No, you cannot. Ghostscript consumes Postscript or PDF, not Doc. | 10:59.37 |
| Arya_ | oh. I thought so. Now comes the hardtime to convince the client :-( | 11:00.20 |
| chrisl | Your best solution is probably to use a "PDF printer" from an application that can open .doc format files | 11:00.21 |
| kens | You can print the doc files to a PostScript file, then convert that. | 11:00.23 |
| | which works as per chrisl's comment | 11:00.38 |
| paulgardiner | As you thought: fwrite to pio->fstdout. What's the best work around for that failing? | 11:01.09 |
| chrisl | paulgardiner: you can redirect stdout/stderr to a file | 11:01.44 |
| paulgardiner | Should I hardwire that in the METRO build? Maybe to disc files in the app's temp directory? | 11:02.31 |
| Arya_ | @chris and kens : thanks for your valuable input | 11:02.46 |
| Robin_Watts | Or, possibly easier, you can supply an fstdout_fn | 11:02.47 |
| | and then redirect to OutputDebugString and actually see the error messages. | 11:03.01 |
| paulgardiner | Yeah that sounds good. | 11:03.49 |
| chrisl | For testing you can just add "-sstdout=filename" to the command line params | 11:03.52 |
| Robin_Watts | paulgardiner: gsapi_set_stdio, and give it 3 functions. | 11:04.09 |
| paulgardiner | Thanks. | 11:04.53 |
| Robin_Watts | tor8: fixed patch online. | 11:06.37 |
| | tor8: I deliberately was keeping the paragraph analysis separate from the text extraction. | 11:11.55 |
| | For things like simple text extraction it doesn't matter. | 11:12.13 |
| | For searching you don't need the overhead etc. | 11:12.24 |
| | In your RTL commit you push the text extraction into the free device routine, which feels wrong. | 11:13.40 |
| | And I can never see where the rtl stuff is actually called. | 11:13.51 |
| | Can we just have the rtl stuff done in the free call, and leave the paragraph/column analysis as something people can call seprately ? | 11:14.17 |
| paulgardiner | Now have a fatal error -100, but it's not issued via gs_log_error so not breaking on it. Am seeing "Unable to open the initial device, quitting" from stdout. What the best way to locate that? | 11:33.08 |
| kens | what device is that ? | 11:33.47 |
| Robin_Watts | paulgardiner: This is -sDEVICE=bogus? | 11:34.11 |
| | or did you go back to -sDEVICE=pdfwrite ? | 11:34.20 |
| paulgardiner | No. Changed it back... I think. | 11:34.32 |
| | Yes. | 11:34.41 |
| kens | then it means the file couldn't be opened | 11:34.55 |
| | output file* | 11:35.01 |
| paulgardiner | ah right | 11:35.12 |
| Robin_Watts | So in order to open pdfwrite, it means it's tried to open the -sOutputFile=.... (or -o ...) file. | 11:35.14 |
| | Are you now seeing the error return code making it back to the caller ? | 11:35.43 |
| kens | You can break in pdf_openif you really want to debug it | 11:35.56 |
| paulgardiner | yes, error gets back to caller. | 11:36.26 |
| Robin_Watts | last I heard last week, the problem was that you were calling the API and you were always getting "success" reported, so you've obviously got further now. | 11:36.45 |
| | Is the -sOutputFile=... in the right directory ? | 11:36.59 |
| | (i.e. in the only directory that windows RT will let you write into) | 11:37.11 |
| kens | Is it present and properly spelled ? :-) | 11:37.11 |
| paulgardiner | Seems to be. It's generated in the same way as stdout, and that is being created. | 11:38.33 |
| kens | You may have to debug it then, or send the code to me and I'll have a go | 11:39.15 |
| paulgardiner | Robin_Watts: the always having success reported was just me being daft. Soon saw what the problem was once I got debugging working | 11:39.38 |
| Robin_Watts | paulgardiner: Oh! | 11:39.56 |
| | pdfwrite uses temporary files, right? | 11:40.02 |
| | Maybe we should try a bitmap output? | 11:40.15 |
| paulgardiner | kens: thanks, but I may aswell battle on for a bit. | 11:40.17 |
| Robin_Watts | -sDEVICE=png16m -o out.png tiger.eps | 11:40.30 |
| kens | I would leave pdfwrite until later ppersonally | 11:40.35 |
| paulgardiner | Robin_Watts: I had to drop all the png devices, so I'd guess that wouldn't work | 11:41.18 |
| | drop from the build. | 11:41.28 |
| Robin_Watts | -sDEVICE=ppmraw -o out.ppm tiger.eps | 11:41.39 |
| paulgardiner | Ok. I'll give that a try. | 11:42.20 |
| Robin_Watts | Woo Hoo! Right side up text! | 11:42.25 |
| paulgardiner | And I have a ppm of a tiger (which my desktop cleverly shows me in the file icon, although Windows claims it has no program that can open it!) | 11:46.00 |
| Robin_Watts | paulgardiner: Most excellent! | 11:46.48 |
| paulgardiner | So ppmraw works but pdfwrite not. | 11:46.53 |
| Robin_Watts | Well, as I say, pdrwrite uses temp files (I believe) | 11:47.05 |
| kens | It does, always | 11:47.11 |
| Robin_Watts | s/r/f/ | 11:47.12 |
| paulgardiner | temp files should work. | 11:47.16 |
| Robin_Watts | hazards to suggest that they don't :) | 11:47.32 |
| kens | Possibly they don't.... | 11:47.35 |
| | Or it could be something else, time to break out the debugger | 11:47.52 |
| Robin_Watts | Now, try adding -r600 | 11:47.54 |
| | before tiger.eps | 11:48.15 |
| | That will tell it to use 600dpi. | 11:48.22 |
| | That should force it into using clist (and hence temp files) | 11:48.41 |
| paulgardiner | I'm using the tempfile opening call (can't remember what it's called) to open the file that I write the args to, and that appears. | 11:48.47 |
| Robin_Watts | paulgardiner: Ah, ok. | 11:49.00 |
| | well, the -r600 test is still not a bad one. | 11:49.07 |
| kens | would resort to the debugger | 11:49.19 |
| Robin_Watts | actually, -dMaxBitmap=10000 might be nice too. | 11:49.24 |
| | -sDEVICE=ppmraw -o out.ppm -dMaxBitmap=10000 -r600 tiger.eps | 11:49.47 |
| | If that works, then it's a sign that clist operation is working. | 11:50.02 |
| paulgardiner | I'll give that a go. | 11:50.15 |
| | kens: break point pdf_openif? I can give that a try too. | 11:51.02 |
| kens | Its a place to start | 11:51.11 |
| | One of the first things that routine does is open lots of files | 11:51.43 |
| paulgardiner | Does argument order matter at all? | 11:52.10 |
| kens | Depends on the arguments | 11:52.19 |
| | But usually no | 11:52.26 |
| Robin_Watts | arguments are processed in order. | 11:52.26 |
| paulgardiner | ... just easier to add to the end of my array | 11:52.37 |
| Robin_Watts | pretty much ALL arguments are of the form "set this setting" | 11:52.45 |
| | and then they only get activated when we hit a filename to execute. | 11:53.01 |
| | so you need to put the args before the filenames (or before any 'inline' postscript commands) | 11:53.22 |
| paulgardiner | Ah right, so I mustn't put -r600 after -f | 11:53.38 |
| Robin_Watts | so "-sDEVICE=ppmraw -o out.png -r600 tiger.eps" you can reorder any way you like, except tiger.eps must be last. | 11:54.07 |
| | indeed. | 11:54.09 |
| paulgardiner | Now I have a 98MB ppm | 11:58.45 |
| Robin_Watts | paulgardiner: spot on. | 11:59.31 |
| | Do you have imagemagic installed? | 11:59.39 |
| | ("convert out.ppm out.png") | 11:59.46 |
| paulgardiner | I can see the tiger head in the icon | 12:00.09 |
| Robin_Watts | ok, sounds like you're sorted. | 12:00.24 |
| paulgardiner | oh. I have gimp too | 12:00.25 |
| Robin_Watts | Did you have the -dMaxBitmap=10000 in there? | 12:00.38 |
| | If so, then we're sure that's using clists. | 12:00.54 |
| | it could be using clist memory rather than clist files though, I guess. | 12:01.22 |
| paulgardiner | Oh weird. It fails intermittently | 12:01.35 |
| Robin_Watts | Fails how? | 12:02.07 |
| paulgardiner | fatal error. | 12:02.20 |
| | Possibly pdfwrite would have done the same if I'd have given it more tries | 12:04.48 |
| kens | pdfwrite probably opens a *lot* more files, so if the file open process 'sometimes' fails, then maybe not | 12:05.28 |
| | It sort of sounds like a temporary file problem though | 12:05.49 |
| Robin_Watts | Remove the -r600 and -dMaxBitmap and see if you get indeterminate failures without them? | 12:06.34 |
| | If not, that would point to it being temporary files occasionally failing. | 12:06.52 |
| | If you still get failures, it would indicate that temp files are not the issue. But it could still be output file issues I guess. | 12:07.23 |
| paulgardiner | Is there a good "noop" argument so I can remove args without renumbering? | 12:07.34 |
| Robin_Watts | -dBOGUS=1 | 12:07.48 |
| | -dXXXXX=y means "Set the dictionary entry XXXXX to be integer y" | 12:08.20 |
| | -sXXXXX=y means "set the dictionary entry XXXXXX to be string y" | 12:08.39 |
| | It's either the system dict or the user dict; it's where postscript devices look for their setup. (I will now be corrected by kens or chrisl who actually understand postscript :) ) | 12:10.16 |
| paulgardiner | Not able to get a failure so far without the extra args. I'll try putting them back and breakpointing the windows bits I've added. | 12:10.24 |
| kens | I believe the values are stored in systemdict | 12:11.05 |
| Robin_Watts | could it be that the thing that's making the thumbnails for the file is holding the file open when gs comes to rerun and so the file open fails? | 12:11.24 |
| | Larger files => longer time to thumbnail, hence more chance of failures? | 12:11.41 |
| | probably not, but I thought I should mention the idea in case.... | 12:12.00 |
| paulgardiner | Good thought, but the thumbnail is visible only in the copy I dragged out of the W8 client to the W7 host | 12:12.28 |
| Robin_Watts | oh, right. that makes sense. | 12:12.58 |
| kens | If pdfwrite always goes wrong it may be the easiest one to debug | 12:15.01 |
| paulgardiner | I bet it's GetTempFileName being called twice within 1ms and giving back the same filename. That would happen if my test for whether the file already exists doesn't work. | 12:34.38 |
| Robin_Watts | paulgardiner: Ah. | 12:35.26 |
| paulgardiner | A guess, but could be it. | 12:35.43 |
| Robin_Watts | sounds plausible. | 12:36.24 |
| paulgardiner | Even more so now I've spotted "if (h = INVALID_HANDLE_VALUE)" | 12:37.10 |
| Robin_Watts | oops :) | 12:40.30 |
| paulgardiner | And now I have a pdf version of tiger. | 12:50.22 |
| tor8 | Robin_Watts: we could separate them completely, yes | 12:51.13 |
| paulgardiner | Robin_Watts, kens, chrisl: what would you recommend I do about the problem with stdio? It looks like it wont work without a stdout redirection, so perhaps I should make METRO builds provide a default one. | 12:57.08 |
| Robin_Watts | paulgardiner: excellent news about the pdf version of tiger. | 12:57.36 |
| kens | Seems like a plan | 12:57.39 |
| Robin_Watts | tor8: so can I pass that back to you? | 12:57.48 |
| | paulgardiner: What would the default one do? | 12:58.02 |
| | I think we do need to provide a default, yes. | 12:58.21 |
| paulgardiner | Not sure. Could write to the temp area | 12:58.28 |
| Robin_Watts | stdin being empty seems sensible. | 12:58.35 |
| paulgardiner | Or Call OutputDebugString | 12:58.53 |
| Robin_Watts | stdout and stderr going to nowhere, or to OutputDebugString in debug builds would be my favorite. | 12:59.00 |
| | If people want to redirect to a temp file, they can do that themselves. | 12:59.15 |
| paulgardiner | Yeah | 12:59.26 |
| henrys | kens:I should get to your reductions today the first one got me sidetracked off to an XL bug. | 13:00.20 |
| kens | stdout output just confuses users generally | 13:00.23 |
| | henrys no rush, I'm working ont he crash. I have a fix but it causes a lot of ther seg faults | 13:00.41 |
| henrys | kens:dangling pointers to fonts? | 13:01.38 |
| kens | I thnk so, the fm cache is pointing at fonts that are no longer present | 13:02.03 |
| paulgardiner | So for METRO builds I should add a call to gsapi_set_stdio to one of the init functions, but which one? | 13:02.18 |
| Robin_Watts | gsapi_new_instance ? | 13:03.08 |
| | That's guaranteed to be the first thing called, right? | 13:03.19 |
| | IF you do: Ctrl-Shift-F in VS and search for "gsapi_set_stdio" in the whole solution you can see lots of places where we call: | 13:06.22 |
| | gsapi_new_instance(...) ; gs_set_stdio(...); | 13:06.43 |
| | so any default setting needs to happen in gsapi_new_instance. | 13:07.01 |
| | presumably there must be some default setting in there anyway? | 13:07.14 |
| tor8 | Robin_Watts: sure. I'll split them into separate passes, and make the RTL one implicit. | 13:07.17 |
| paulgardiner | Great ta | 13:07.32 |
| Robin_Watts | mem->gs_lib_ctx->stdin_fn = NULL; | 13:07.47 |
| | mem->gs_lib_ctx->stdout_fn = NULL; | 13:07.49 |
| | mem->gs_lib_ctx->stderr_fn = NULL; | 13:07.51 |
| | I have text in the right size, in the right place now. Still in the wrong font. | 13:09.02 |
| henrys | Robin_Watts:you have all the different font types working already? | 13:37.53 |
| | Robin_Watts: that's very fast progress. | 13:38.11 |
| | someday I'll redo pass thru mode, today is not the day. | 13:56.35 |
| tor8 | Robin_Watts: looking for a more descriptive name of fz_text_analysis... | 14:00.30 |
| | candidate: fz_sort_paragraphs or something like it | 14:01.08 |
| Robin_Watts | henrys: I have no font types at all working. | 14:05.50 |
| | I just the font name through, no font data. | 14:06.11 |
| | tor8: well, the routine analyses text. Columns/Indents/Paragraphs spacing etc. | 14:06.58 |
| | text_analysis seems like the right name to me :( | 14:07.06 |
| | henrys: Have you ever considered mupcl ? | 14:07.29 |
| tor8 | fz_analyze_text then | 14:11.12 |
| henrys | Robin_Watts:I've thought about it, it would be more compelling if PCL were not so tied to printing. | 14:11.16 |
| Robin_Watts | Stroked text is problematic. | 14:12.18 |
| | or at least, it's problematic with the way I'm handling transforms. | 14:12.33 |
| paulgardiner | It gets weirder: with my io override in place, it crashes in a memmove in stream_compact. | 14:31.39 |
| | Doh! | 14:32.22 |
| Robin_Watts | hehe | 14:32.39 |
| paulgardiner | Other than having a large number of devices removed, it seems to be working now: http://git.ghostscript.com/?p=user/paulg/ghostpdl.git;a=summary | 15:03.35 |
| | chrisl: I haven't updated the way winrtsup.cpp is built. I thought I may as well take you up on your offer to sort it out. | 15:05.25 |
| chrisl | paulgardiner: sure, no problem. I'll do it when you commit the changes to master - if you remind me! | 15:06.19 |
| tor8 | Robin_Watts: fixed patches on tor/master | 15:19.05 |
| kens | OK I'm off goodnight folks | 16:54.14 |
| mvrhel_laptop | henrys: you around? | 20:44.16 |
| henrys | yes mvrhel_laptop | 20:44.30 |
| mvrhel_laptop | just wanted to give you a update on where I am with the windows viewer. | 20:44.46 |
| | a lot of my rewrite is done | 20:44.54 |
| henrys | mvrhel_laptop: oh are you out for the meeting tomorrow? | 20:45.13 |
| mvrhel_laptop | no I will be there | 20:45.21 |
| | I can give the update then | 20:45.28 |
| | I may have a few more things done by then :) | 20:45.38 |
| | the rewrite started out slow, but now things are coming together quickly | 20:45.54 |
| | and it is much cleaner now | 20:45.59 |
| henrys | mvrhel_laptop: the group probably will have better feedback than me alone anyway. | 20:46.01 |
| mvrhel_laptop | ok | 20:46.06 |
| | maintaining and adding new features will be much easier now. | 20:46.20 |
| | later part of this week I need to get ready for open printing talk | 20:46.31 |
| henrys | it might be good if you can get things pushed up on your branch | 20:46.41 |
| mvrhel_laptop | Robin_Watts is going to help me with some of the mu pdf details | 20:47.02 |
| | henrys: yes, I am pushing it all up now each day | 20:47.20 |
| | I was not for awhile when I had everything in shambles | 20:47.34 |
| henrys | good I'll try to study it a bit before the meeting. | 20:47.50 |
| mvrhel_laptop | ok. two main projects are mupdfwinrt which has two classes. mudocument which is the interface between winRT and another class muctx which does all the calls to the mupdf library | 20:48.38 |
| | the other project is mupdf_cpp which is the viewer code as a c++ project | 20:49.03 |
| | I started a csharp viewer too, but that is not checked in | 20:49.32 |
| | the c++ viewer may be sufficient for a demo | 20:49.49 |
| henrys | maybe we should have a winrt device at chicago in September. | 20:50.46 |
| mvrhel_laptop | yes. that would be a good idea | 20:51.00 |
| | off to get the kids from school. bbiaw | 20:51.41 |
| henrys | hopefully it is not going to be really difficult to implement features on many devices. For example paulgardiner is probably close on having digital signatures, but how easy does that get moved over to winrt or iOS? | 20:52.29 |
| | bbiaw | 20:58.59 |
| mvrhel_laptop | henrys: if he has an easy interface to mupdf then it should be very easy to port to winrt the way that I have things written | 23:01.49 |
| | i hope | 23:01.58 |
| | Forward 1 day (to 2013/05/07)>>> | |
IRC Logs