| | <<<Back 1 day (to 2014/10/27) | 20141028 |
| mvrhel_laptop | henrys: can you do me a favor | 02:28.45 |
| | can you copy the latest copy of GS9_Color_Management.pdf to the web site location on casper (i.e. in doc/current). I don't have permission to do this | 02:30.58 |
| | Miles wanted it updated with a newer copyright date. | 02:31.16 |
| | bbiab | 02:35.18 |
| henrys | mvrhel_laptop: when is current updated? rather than fix your one piece of documentation why not a cron job that updates the tree to head? | 03:32.14 |
| | mvrhel_laptop: ah current is current release so I'd be inclined to either change the definition of what we mean by current and copy everything in or tell miles to wait until march. | 03:36.10 |
| mvrhel_laptop | henrys: right I was trying to understand that | 03:44.52 |
| | I don't think Miles will want to wait until March though | 03:45.54 |
| henrys | mvrhel_laptop: let's talk to chrisl_away about it at the meeting. He updates it each release I guess, based on the dates I see. | 03:45.56 |
| mvrhel_laptop | ok | 03:46.03 |
| henrys | mvrhel_laptop: I think we can make a good case "current" should be now | 03:46.47 |
| mvrhel_laptop | yes | 03:46.54 |
| pedro_mac | morning folks | 07:36.13 |
| dinamic | tor8: i made 2 PR on github against your mujs project which fixes two bugs | 10:53.57 |
| tor8 | dinamic: thanks. I've pushed a fix for the JSON parsing issues you and avih have discovered, and another one I found while looking into it. | 11:23.02 |
| | in the future, please use bugs.ghostscript.com though. just stick it under the MuPDF category and prefix with [mujs]. I'll see about getting our sysadmin to add a category for MuJS to the bugzilla later today. | 11:24.01 |
| dinamic | tor8: great | 11:36.48 |
| avih | tor8: k. btw, i think i got the stack handling wrong in c calees. how should the callee handle the stack? just push a singe value as the return value? what happens if a callee pops some of its arguments? | 12:16.38 |
| | (the print example doesn't pop anything, and the pcall docs says the caller should pop the arguments it's pushed, so i guess callees should not manipulate the stack beyond adding a return value) | 12:18.02 |
| | also, any plan to push the debug patch to master? fwiw, preliminary speed tests which i tried (looping function call) didn't show meaningful speed difference with it, and it's very very useful (the line info on errors) | 12:20.41 |
| tor8 | avih: the value on the top of the stack is returned, all other values are ignored (and automatically popped when the function returns) | 12:21.40 |
| avih | also, i think that's quite expected from a js vm to report line numbers on errors. | 12:21.42 |
| tor8 | avih: the debug patch needs more polishing | 12:21.55 |
| avih | tor8: ok, so re c functions, what happens if the callee pops the arguments? would it mess things up or would the vm wrapper just clean js_gettop regalrdless if the callee popped some values or not? (Assuming it didn't pop beyond the this value) | 12:23.11 |
| tor8 | avih: popping more values than there are arguments will lead you into undefined territory | 12:26.04 |
| avih | but if the callee pops the arguments, then no hard done? (even if not required, which i just got wrong) - trying to figure out of my crashes are due to incorrect handling of the stack | 12:28.34 |
| | harm* | 12:28.48 |
| tor8 | avih: as long as you don't pop more than you had coming in, you're safe | 12:43.57 |
| | but you must push or leave at least one argument on the stack, as the return value | 12:44.09 |
| avih | k, thx | 12:44.44 |
| | (yeah, i did the latter, but somehow incorrectly thought the calle should also pop the args) | 12:45.06 |
| tor8 | avih: if you're in doubt about how something works, the builtin functions are usually decent examples | 12:46.08 |
| | in jsarray.c, jsobject.c, etc | 12:46.27 |
| avih | bug http://bugs.ghostscript.com/show_bug.cgi?id=695567 has a commit link which is not found, and also it doesn't show on http://git.ghostscript.com/?p=mujs.git;a=summary | 13:06.00 |
| tor8 | avih: the bugzilla commit links all point to the same (wrong) repo :( | 13:17.53 |
| | http://git.ghostscript.com/?p=mujs.git;a=commit;h=8a659b28210220f6e29d5ed671e2c22adde9a7c1 | 13:18.44 |
| avih | oh, i missed the commit data (oct 9th), the bug was from today so i was looking at the recent log for the fix. i now see it earlier at the log | 13:21.33 |
| dinamic | avih: to get stuff right i imlpemented a stack dumper, that has solved alot of issues for me, it just prints X items on stack from top | 13:21.38 |
| avih | date* | 13:21.39 |
| tor8 | dinamic: jsR_dumpstack? | 13:22.34 |
| avih | dinamic: well.. my issues right now are random crashes. i can't tell if it's the js parts or the embedding parts.. :/ | 13:22.42 |
| dinamic | tor8: i have missed that one :) | 13:23.04 |
| tor8 | dinamic: it's private, so easy to miss | 13:23.41 |
| dinamic | tor8: mm, i just used js_tonstring(state, x) | 13:24.02 |
| tor8 | you can use the js 'debugger' statement to get it to dump the stack and bytecode | 13:24.17 |
| avih | (i've implemented about 7-8 c apis which the js code can access, and for the most part it works great, except for crashes manifest differently every time (Segfaults, deallocations, etc, and only some of those are js related, and it's just completely not deterministic :/ ) | 13:24.36 |
| tor8 | avih: have you tried running it in valgrind yet? | 13:25.02 |
| avih | not yet | 13:25.09 |
| | and on top of that i think that this MBA (4 years old) might have issues of its own. i've experienced random crashes or hangs on it, relatively rarely, but more than a year ago for sure. so between the laptop hardware, the js implementation, my use of it and the embedding environment, and with the random symptoms, it's really hard :/ | 13:26.39 |
| | and while my crashes are random, they happen consistently up to few seconds from starting the app in most cases. but still not deterministically as far as i can tell | 13:27.54 |
| | (it's a code with manyy callbacks both ways between the js code and the client code, observers, timeouts, etc) | 13:28.40 |
| tor8 | I hope you're not trying to call mujs from multiple threads... | 13:29.03 |
| | ...on the same js_State | 13:29.11 |
| avih | nono, single thread | 13:29.31 |
| | and the thread is dedicated to run the js code | 13:31.26 |
| marcosw | henrys: I have to take my daughter for a doctor's appointment this morning and so will miss the IRC meeting but should be back in time for the SOT meeting. I'lll read the logs. | 13:39.09 |
| tor8 | marcosw: could you please add MuJS as a bugzilla component? | 13:40.11 |
| marcosw | sure, under MuPDF? | 13:40.42 |
| | I presume. | 13:40.46 |
| | or as it's own product? | 13:41.34 |
| kens | Own product seems to make sense ? | 13:41.43 |
| Robin_Watts_ | I'd vote for own product. | 13:42.24 |
| | Similarly, under GhostDocs, could you add components for "UI", "Renderer" and "Core" please? | 13:44.16 |
| dinamic | avih: i use alot of callbacks etc in my project, you might get some info from my code | 13:45.44 |
| | avih: mujs objects are in https://github.com/hean01/castio/tree/master/src/js | 13:46.51 |
| avih | dinamic: i wouldn't mind looking. thx. my code is running in its own thread, basically running js code which binds to client api of the application i'm trying to control. so it could definitely be incorrect use of the client api for the application. | 13:47.45 |
| | the client api supports observers, timeouts, etc, so all that binds back to the js code. and the thing is, all the code paths work as far as i can tell, but then there are these random crashes. | 13:48.49 |
| | i.e. all the observers and c functions which the js can call work... | 13:50.06 |
| | just not for long enough :) :/ | 13:50.20 |
| dinamic | avih is the timeouts / observer callbacks syncronous with your thread ? do you queue up request for dispatch to force synchronous operations on the js state? | 13:54.28 |
| | avih: ^ just thinking out loud | 13:54.47 |
| avih | the (js) client thread is synchronous and waits in an event-loop style on the client api wait_event. so whenever it gets an event, it executes js code accordingly. | 13:56.09 |
| | the wait event api call returns after a specified timeout argument or whenever an actual event arrives from the application | 13:57.03 |
| dinamic | that sounds synchrnous enough :) | 13:57.35 |
| avih | the js code can forther execute other client api calls | 13:57.49 |
| | further* | 13:57.59 |
| | sync or async really depends on your point of view :) | 13:58.15 |
| dinamic | ah ok, which would raise an event and get back into the state to execute something other | 13:58.18 |
| | that ^ would require a proper stack handling or it will get very messy | 13:58.55 |
| avih | there's a single client thread, and it doesn't spawn more threads. it basically loops as wait event -> execute js code -> the js code can call more app api calls -> returns -> wait for another event | 13:59.11 |
| dinamic | when something is done executing, the stack should look as just it would when you entered | 13:59.34 |
| avih | yup | 13:59.44 |
| dinamic | so if your leave traces on stack it will mess up furteher execution | 13:59.56 |
| avih | sure | 14:00.06 |
| dinamic | if you say it happens random, can you pinpoint any event that will raise the issue ? | 14:00.15 |
| | specific event ? | 14:00.20 |
| avih | no | 14:00.37 |
| | at least not that i could find | 14:00.44 |
| | i _think_ many of the times it actually crashes on the wait_event call | 14:01.00 |
| dinamic | implement a log cfunction and in javascript log each function call | 14:01.04 |
| tor8 | marcosw: own product, please | 14:01.16 |
| avih | it doesn't crash inside the js execution as far as i can tell | 14:01.23 |
| dinamic | oh ok | 14:01.55 |
| avih | dinamic: i mostly have that. i can track the code flow. like i said, most of the time it crashes at the alient api call which waits for the next event | 14:02.23 |
| | it could still be due to messed up stack, but it could also be incorrect use of the client api, or faulty hw (which is another suspicion i have since it crashes more than it used to in the past regardless of my project) | 14:03.20 |
| dinamic | so what does a backtrace tell you of the crash ? | 14:04.43 |
| zeniko | tor8: I've got two small fixes on zeniko/mupdf for review | 14:12.31 |
| | also, is there any reason for not merging your "Fix warnings." commit? | 14:13.27 |
| tor8 | zeniko: no reason, they just haven't been reviewed yet | 14:14.14 |
| zeniko | ah, does an "it works for me and LGTM" from my part suffice for review? | 14:14.44 |
| tor8 | zeniko: yes :) | 14:15.53 |
| zeniko | henrys: there are two minor patches to jbig2dec on zeniko/ghostpdl for review and merging which fix some unfortunate regressions introduced with the last fuzzing fixes in January | 14:16.30 |
| henrys | zeniko: thanks I'll look after the meetings today - in an hour or so. | 14:17.57 |
| zeniko | henrys: thanks, no hurry | 14:18.27 |
| | tor8: BTW: any plans to update MuPDF to also use openjpeg 2.1.0? | 14:19.41 |
| tor8 | zeniko: eventually. we're a bit understaffed on the mupdf side of things with the whole smartoffice deal, so it may be a while until I get time. | 14:20.20 |
| | Robin_Watts_ has been handling the openjpeg integration, so he may do it on those days when he needs a breather from smartoffice | 14:21.19 |
| zeniko | Well, maybe 2.2.0 will be out soon anyway, now that pdfium also uses openjpeg and has had Google produce another round of fuzzing crash reports :-/ | 14:21.46 |
| nsz | what is smartoffice? | 14:22.09 |
| kens | Another product | 14:22.36 |
| nsz | i could guess that much.. | 14:22.59 |
| kens | Google then | 14:23.09 |
| nsz | nothing relevant turns up | 14:24.06 |
| tor8 | kens: I don't think smartoffice has that much google foo; it's all in the app stores | 14:24.25 |
| kens | If I google SmartOffice Artifex it takes me to the right page as hte first link | 14:24.30 |
| henrys | http://smartoffice.artifex.com/ | 14:24.49 |
| kens | Same if I just Google SmartOffice | 14:24.53 |
| nsz | i dont use google but thanks | 14:25.00 |
| | i used ddg.gg | 14:25.05 |
| kens | 5 minutes to meeting ? THe US hasn't changed times yet, right ? | 14:25.35 |
| henrys | kens: no | 14:25.50 |
| | oh god we're in that again... | 14:26.00 |
| tor8 | kens: a 'neutral' google search (one that ignores your logged in account) has the android and itunes app stores as hit #7 and #8, picsel.com as hit #4 and all other hits irrelevant | 14:27.21 |
| kens | Well surely the app sotre hits would be enough to see what it is ? | 14:27.40 |
| tor8 | kens: well, there's a lot of other stuff on the page as well, so if you don't know what you're looking for I can imagine it being a bit confusing | 14:28.11 |
| | picsel.com is labeled "Artifex SmartOffice" though :) | 14:28.16 |
| kens | Even a 'neutral' google still gives me Artifex's page as hte first hit | 14:28.35 |
| tor8 | we need to improve http://smartoffice.artifex.com/ google rank | 14:28.39 |
| kens | THat is google.co.uk though | 14:28.44 |
| henrys | I just tell people the link ... | 14:28.48 |
| tor8 | kens: neutral uk region search gets me picsel.com as the #1 hit, true | 14:29.09 |
| kens | Stupid CHrome won't let me use Google.com..... | 14:29.29 |
| tor8 | kens: google.com/ncr | 14:29.37 |
| henrys | for gs and mupd it's lmgtfy.com | 14:29.38 |
| tor8 | as in no-country-redirect | 14:29.44 |
| henrys | or mupdf | 14:29.47 |
| nsz | on ddg.gg it's not in the first 10 | 14:30.03 |
| tor8 | nsz: duckduckgo has smartoffice app store hits on the first page | 14:30.39 |
| nsz | i thought that's surely something else.. | 14:30.59 |
| | appstore hits are mostly spam | 14:31.10 |
| tor8 | I also use duckduckgo as my primary search engine; with !g for those rare occasions when I need an unrefined google search result | 14:31.36 |
| henrys | kens: so chrisl_away is possibly not here because of the time? | 14:32.09 |
| nsz | i use !s for that :) | 14:32.14 |
| kens | I'm probably irritable, drowning in stupid bug reports and fighting clist | 14:32.24 |
| | henrys, I would have to guess so, yes | 14:32.31 |
| nsz | (i use ddg because it has it's /lite/ version that is very usable from w3m unlike other websearch things) | 14:32.55 |
| rayjj | kens: which clist issue are you fighting ? | 14:33.54 |
| tor8 | nsz: my only gripe with ddg is I can't blacklist useless sites like answers.yahoo.com and about.com | 14:33.56 |
| henrys | well I'll leave something for the logs chrisl_away we, well mvrhel_laptop and henrys would like the current docs on ghostscript.com to point to the current code not the last release. | 14:34.04 |
| kens | rayjj getting my FirstPage/LastPage stuff to work, its all new | 14:34.08 |
| henrys | kens: hey so that is coming along? | 14:34.39 |
| kens | henrys, its getting there, clist is my current headache with it, but since I only started in on that part today I'm not surprised. | 14:35.04 |
| | In general the code works, and works with all interpreters provided they send -dFirstPage and/or -dLastPage to the device put_params | 14:35.35 |
| rayjj | kens: I see -- you're trying to avoid processing stuff into the clist ? | 14:35.38 |
| henrys | mvrhel_laptop: I was going to ask marcosw about xpswrite commits. I guess he'll look at the logs and give the okay. | 14:35.43 |
| mvrhel_laptop | ok. that would be good. I | 14:36.01 |
| nsz | tor8: btw i made progress with floating-point formating, i have a reasonably small fp formatter that can do toExponential, toPrecision, toFixed and the normal tostring with shortest decimal form | 14:36.04 |
| kens | rayjj, no its more complex than that, to be honest I'm not sure what;'s wrong at the moment, the cluster test only finished a bnit back and I';ve been fending off bug reports | 14:36.07 |
| rayjj | kens: OK. let me know if you have questions and I'll *try* to help. | 14:36.51 |
| kens | henrys, it works with all the interpreters (specifically including the PostScript interpreter), works with transparency, and the high level devices. As soon as I fix whatever I broke in clist processing it shold be close to being ready, though it'll need a lot of tidying up and maybe some thought about other things it should do. | 14:37.11 |
| mvrhel_laptop | maybe when chrisl is in there making currrent, current we can get this page updated too | 14:37.22 |
| | http://www.ghostscript.com/Documentation.html | 14:37.24 |
| henrys | maybe we should have scheduled vacations from non customer problems ;-) | 14:37.26 |
| kens | rayjj I think I'm clear on the clist, there are some interesting things I found while working on this, I'm currently documenting them as I go as comments in my new C file. | 14:37.43 |
| rayjj | henrys: I saw the discussion between mvrhel_laptop and you about "current" on the website. As long as the docs and the code match, that's OK, but AFAIK the 'current' code is the most recent release | 14:38.14 |
| | and we don't want the docs to describe some feature that's not in the 'current' code | 14:38.36 |
| henrys | rayjj: right it is but we'd like to change it. | 14:38.46 |
| rayjj | that's what the gig blobs are for, IMHO | 14:38.52 |
| kens | had a free user on SO wondering why the current documentation on silent installsations on Windows (form our web site) didn't work when he tried to install 8.70...... | 14:38.53 |
| rayjj | s/gig/git/ | 14:39.18 |
| mvrhel_laptop | oh | 14:39.22 |
| | it is updated | 14:39.24 |
| nsz | (but i found an issue in my math rounding functions in musl and possibly freebsd/android/.. fdlibm __rem_pio2 that only affects i386 so i want to figure that out first before finishing the fmtfp) | 14:39.25 |
| kens | mvrhel_laptop : Chrisl may have updated it when he fixed some documentation today | 14:39.42 |
| mvrhel_laptop | oh cool | 14:39.50 |
| | for the logs, thanks chrisl | 14:40.26 |
| kens | He updated the docs for fonts and COMPILE_INITS, he may have done rthe web site at the same time | 14:40.27 |
| rayjj | henrys: AIUI, Miles is looking for 'bleeding edge latest' as opposed to 'current release' | 14:40.30 |
| mvrhel_laptop | the doc, in question was not up to date in this particular case rayjj | 14:40.59 |
| henrys | rayjj: we are trying to solve a problem for miles also but that is secondary. | 14:40.59 |
| kens | Hmm, we want the 'latest' docs on the web site, even if they are newer than the latest release ? I'm not sure that's wise | 14:41.09 |
| | Having up to date docs makes sense though of course | 14:41.38 |
| mvrhel_laptop | perhaps a pre-release doc folder in http://www.ghostscript.com/doc/ | 14:42.42 |
| kens | THat would OK to have too, a sort of sneak preview of what's coming | 14:43.02 |
| rayjj | kens: the 'latest from the repo' _is_ on the web. For example: http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=gs/doc/Readme.htm;hb=HEAD | 14:43.16 |
| tor8 | zeniko: there's a typo in 'more liberally accept page trees with unexpected content', too many ) | 14:43.21 |
| henrys | mvrhel_laptop: yea so miles just needs a different link I gave him "current" | 14:43.30 |
| kens | rayjj : THat's what Michael said a minunte ago (I think) | 14:43.32 |
| | But I'm not sure its a good idea, if the docs are more recent than the release. As you say, what happens if we add a feature ? | 14:43.59 |
| henrys | mvrhel_laptop: does prerelease have your change for copyright dates? | 14:44.11 |
| kens | And there's a chrisl :-) | 14:44.17 |
| chrisl | Yeh, sorry, forgot the clocks had changed | 14:44.29 |
| mvrhel_laptop | henrys: we are all set as far as miles goes now | 14:44.30 |
| | chrisl updated current | 14:44.39 |
| rayjj | at least the git repo is self-consistent | 14:44.46 |
| henrys | mvrhel_laptop: well I went to some effort to have miles point to the documentation not copy it. Have we kept that intact? | 14:45.04 |
| mvrhel_laptop | yes. the link you gave him will work now | 14:45.21 |
| | I will let him know that it is all good now | 14:45.38 |
| henrys | chrisl: don't read the logs | 14:45.38 |
| chrisl | I put a cron job in place so current gets updated from git every hour | 14:45.41 |
| mvrhel_laptop | :) | 14:45.43 |
| henrys | ;-) | 14:45.43 |
| kens | chrisl but what if we add features and document them ? THen the docs will be out of sync with the release | 14:46.06 |
| henrys | chrisl: web site looks nice! | 14:46.09 |
| kens | THe web docs that is | 14:46.10 |
| chrisl | kens: there are still the docs for each release, plus the "current" docs | 14:46.33 |
| mvrhel_laptop | right | 14:46.38 |
| kens | Aha! OK that makes sense | 14:46.42 |
| mvrhel_laptop | thats what I was showing in the above link http://www.ghostscript.com/doc/ | 14:46.58 |
| kens | SOrry mvrhel_laptop I was doing something else and missed it | 14:47.10 |
| zeniko | tor8: sorry about that, it should compile now | 14:47.15 |
| kens | Trying to figure out what is broken in a PDF file..... | 14:47.33 |
| henrys | I was going to bug tor8 about epub status, but other than that I don't have anything else. Anybody else have stuff for the gs/mupdf meeting? | 14:47.46 |
| rayjj | thehttp://www.ghostscript.com site doesn't look good for me with Firefox | 14:47.58 |
| kens | Not from me, plenty to keep me busy at the moment | 14:48.04 |
| | rayjj looks OK to me, what do you see as a problem ? | 14:48.19 |
| mvrhel_laptop | looks fine on my Firefox | 14:48.23 |
| rayjj | chrisl: do you want a screenshot ? | 14:48.36 |
| kens | is using 32.0.3 | 14:48.42 |
| chrisl | rayjj: you might need to force a full refresh since the css has changed | 14:48.57 |
| tor8 | henrys: epub is progressing. I have the box generation and block level layout working; need to start on formatting lines and outputting text on pages | 14:48.59 |
| henrys | rayjj: did you refresht? | 14:49.00 |
| | tor8: nice. | 14:49.19 |
| chrisl | henrys: after the discussion with the customer about cidfmap, I'm wondering if we should make the environment variable names and registry entry names a compile time setting (so settable as an configure/nmake option) | 14:49.34 |
| tor8 | henrys: which I expect will be the biggest task of all -- fonts and linebreaking :( | 14:49.41 |
| | henrys: well, that and then floats and tables... plenty left to do! | 14:49.58 |
| | but the groundwork is there | 14:50.02 |
| rayjj | the ghostie is in the top left, then a list of the primary links, *then* the "Ghostscript" header | 14:50.10 |
| kens | Hmm, that's not what I see | 14:50.25 |
| | hat version of Firefox ar eyou using / | 14:50.41 |
| | ? | 14:50.44 |
| mvrhel_laptop | oh I have that at http://www.ghostscript.com/Ghostscript.html | 14:50.44 |
| | too | 14:50.46 |
| | I am at 32.0.3 | 14:50.57 |
| kens | No tha'ts fine for me too | 14:50.58 |
| henrys | chrisl: have we had any other requests for that even non customer? | 14:51.03 |
| rayjj | kens: strange -- it must have had that page from a long time ago -- I haven't been to that page since several reboots ago | 14:51.04 |
| | chrisl: _does_ look nice | 14:51.15 |
| mvrhel_laptop | oh a refresh and it all looks good | 14:51.36 |
| kens | rayjj so its OK for you now ? | 14:51.38 |
| mvrhel_laptop | very nice | 14:51.42 |
| chrisl | henrys: that customer I was dealing with wanted a way to influence *only* their GS install, and not have their install be influenced by any others | 14:52.07 |
| | rayjj: most of the credit goes to tor8...... | 14:52.25 |
| rayjj | kens: I'm running 33.0 but just got a pop-up saying 33.0.1 is available | 14:52.34 |
| chrisl | Firefox doesn't seem to be that good at spotting that the stylesheet has changed ;-( | 14:53.11 |
| kens | Well aboput tells me there's a newer version, but I'm not bothered by keeping that up to date ;-) | 14:53.11 |
| henrys | chrisl: it's reasonable just don't know if we want to do it without a few more requests | 14:53.13 |
| chrisl | henrys: This is the first time I've seen it come up, but I find that surprising | 14:53.52 |
| kens | I guess most people use -I to avoid these sorts of problems ? | 14:54.12 |
| chrisl | Yes, but that doesn't fully solve the problem | 14:54.28 |
| kens | defers to the expert.... | 14:54.54 |
| henrys | chrisl: how about a compromise with a p2 enhancement request with the customer number for now and we'll visit it again at the meeting bug scrub | 14:55.25 |
| chrisl | henrys: could we just add it to workflowy for discussion? I think the customer in question is probably satisfied | 14:56.17 |
| rayjj | for the record, I'm mired in trying to find a 'minimal' patch for an old cust 532 code set for a problem that doesn't occur in ANY of our commits (has to be with the rest of their changes). Len has been wrapped around the axle on it for a couple of weeks | 14:56.24 |
| henrys | chrisl: okay I'll add it. | 14:56.42 |
| kens | That sounds uinpleasant :-( | 14:56.48 |
| chrisl | henrys: Thanks | 14:56.55 |
| rayjj | kens: I would think -I would be sufficient since that comes BEFORE any built-in or registry based search paths | 14:57.24 |
| kens | rayjj chrisl says not, I'll believe him.... | 14:57.38 |
| henrys | fwiw we change time november 2 so next week we should be back to regular times | 14:58.17 |
| rayjj | chrisl: is the problem that the registry based path is taking precedence over -I ? | 14:58.18 |
| chrisl | rayjj: the problem is if you have *another* gs installation, the -I will not stop us picking up files from that | 14:58.18 |
| henrys | chrisl: why can't gs installations be destructive. | 14:59.26 |
| | ? | 14:59.29 |
| kens | Because then you couldn't have multiple installations ? | 14:59.50 |
| chrisl | henrys: I don't think customer would be very happy with that...... | 14:59.54 |
| kens | I have several versions installed at the same time | 14:59.59 |
| chrisl | s/customer/customers | 15:00.06 |
| | If I have a RIP app from a customer *and* a "normal" gs install, both of the same version, the configurations could interact | 15:01.03 |
| Robin_Watts_ | Have I missed the meeting? (Sudden panic about time changes) | 15:01.17 |
| rayjj | chrisl: is the problem the CIDFSUBSTPATH ??? that doesn't appear to follow the *normal* searching rules and uses gentenv deirectly | 15:01.33 |
| henrys | Robin_Watts_: yes our time changes are not in sync | 15:01.37 |
| chrisl | rayjj: no, the problem is the GS_LIB path | 15:01.48 |
| Robin_Watts_ | ass. I had nothing for the meeting anyway, | 15:01.53 |
| henrys | no problem... I didn't see much for you to read back for either. | 15:02.22 |
| rayjj | chrisl: so GS_LIB environment var is taking precedence over command line -I path ? --- that seems like a bug | 15:03.39 |
| kens | Good grief, London metting is only just over 6 weeks already | 15:03.41 |
| chrisl | rayjj: No, nothing is taking precedence over -I | 15:04.00 |
| rayjj | chrisl: but they just want to not include stuff found with GS_LIB ? | 15:04.41 |
| mvrhel_laptop | seems like we just had a meeting | 15:04.45 |
| Robin_Watts_ | kens: Yes, we had a long summer break, hence these two meetings are closer together. | 15:05.24 |
| kens | I know why, its just kind of alarming to have it sneak up like that..... ;-) | 15:05.45 |
| chrisl | rayjj: if I have a customer's Ghostscript 9.15 executable, shipped as part of their application, *and* a "normal" Ghostscript 9.15 executable installed, the customer's GS executable will pick up the GS_LIB setting for the "normal" install | 15:05.52 |
| rayjj | chrisl: but the -I still has precedence, right ? | 15:06.28 |
| Robin_Watts_ | Just to reiterate the invitation; if anyone wants to come visit (either for a day, or overnight) we'd be happy to host them. | 15:06.34 |
| chrisl | rayjj: yes. | 15:06.41 |
| kens | Heh, someone asking if we'll open source SmartOffice for WebOS | 15:06.58 |
| rayjj | if they want their %rom% contents to take precedence over the GS_LIB from the environment, the -I%rom%Resource/Init/ should do it (I think) | 15:07.39 |
| | chrisl: or is the problem that it is picking up something from the "stock" 9.15 that it isn't finding in their paths | 15:09.01 |
| chrisl | rayjj: Yes, that exactly the problem | 15:09.13 |
| rayjj | chrisl: which file is "exactly the problem" ? | 15:09.32 |
| chrisl | In their case, cidfmap | 15:09.40 |
| rayjj | chrisl: If they have a cidfmap shouldn't that be found first ? | 15:10.12 |
| chrisl | rayjj: they were building it into romfs | 15:10.25 |
| | I think it's pretty reasonable for a customer to want to know that their "version" of Ghostscript won't influence, or be influenced by other, random GS installs..... | 15:11.00 |
| rayjj | chrisl: right, and putting %rom%Resource/Init *before* the other (default) paths is supposed to avoid that | 15:11.31 |
| kens | Yes, but you have to kinow to invoke GS that way, I think its surprising, and not obvious | 15:12.06 |
| | At best | 15:12.12 |
| rayjj | and that's what the default code does -- the %rom path is always first | 15:12.15 |
| kens | Not if you have a GS_LIB defined | 15:12.25 |
| | I htink | 15:12.34 |
| chrisl | If you have GS_LIB defined (which if you use the Windows installer you always do) it takes precedence over %rom% | 15:13.06 |
| rayjj | kens: but adding -I%rom%Resource/Init solves that | 15:13.21 |
| kens | rayjj yes, but that's what I meant when I said you have to know to do that, and its surprising and not obvious | 15:13.38 |
| | And we don't document it | 15:13.45 |
| chrisl | And I also think it's a rather hacky solution | 15:13.55 |
| kens | If you know how our path searching works you can figure it out, but its not clear at all that this is going to happen. | 15:14.13 |
| rayjj | kens: with GS_LIB set to "xxx" using: gswin32c -I%rom%Resource/Init -h | 15:14.25 |
| kens | rayjj I'm not saying it doesn't work, I'm saying its surprising behaviour | 15:14.55 |
| rayjj | kens: I get: | 15:15.01 |
| | Search path: | 15:15.02 |
| | %rom%Resource/Init ; xxx ; %rom%Resource/Init/ ; %rom%lib/ ; | 15:15.04 |
| | c:/gs/gs9.16/Resource/Init ; c:/gs/gs9.16/lib ; ... | 15:15.05 |
| kens | TBH If I go to the trouble ofcreating a ROM file system, in order to be self-contained, I'd be baffled by the facft that someone else installing a different version of Ghostscript could cause my installation to change behaviour unless I *also* set -I.... | 15:15.53 |
| rayjj | kens: I thought chrisl was saying that there was no way to do it without modifying the install | 15:15.56 |
| kens | No, he's saying the way it works now is not intuituve, and surprising | 15:16.16 |
| | as well as not documented | 15:16.26 |
| rayjj | kens: I'd be content to have the %rom% contents take precedence over GS_LIB. Since it's not documented, we can make it do that and document it :-) | 15:17.08 |
| kens | Directly that is, nowhere do we say 'and if you want to make sure that the stuff you expleicitly define in your ROM file system doesn't get overridden by random stuff installed by the uiser set -I%rom%...' | 15:17.09 |
| chrisl | rayjj: I was saying it would be nice if there was an easy, well defined way for customers to ensure their GS build to be isolated from random other ones | 15:17.22 |
| rayjj | kens: oops. it _is_ documented that GS_LIB paths take precedence over %rom% paths. See: http://www.ghostscript.com/doc/9.14/Use.htm#Finding_files | 15:18.56 |
| | (or even 'current') | 15:19.38 |
| kens | rayjj yes I know, but that's surprising. I'm not suggesting we change it, but I'm with chrisl that we document it specifically and say 'if you don't want this to happen chenge the defualt GS_LIB and so on' | 15:19.43 |
| | Big warnign somewhere seems appropriate to me | 15:20.10 |
| | If for no other reason than it took chrisl quite a hwile to figure out what was going on..... | 15:20.41 |
| rayjj | kens: well, now that we've all discussed it, it will be a few weeks before we all forget and have to dig it out again ;-) | 15:21.20 |
| kens | Probably true, that's why I'm writing up my findings about devices as comment sin the C file I'm working on | 15:21.43 |
| chrisl | I still think it's understandable that a customer would want to use their own custom environment variable name(s) and registry entry name(s)..... | 15:22.35 |
| kens | Yes, makes sense to me | 15:22.44 |
| rayjj | kens: thank you for that! The docs are usually the last place I look (at least for accurate up to date info) | 15:22.47 |
| | chrisl: which they _can_ do by changing the #define of GS_LIB and re-building | 15:23.44 |
| chrisl | rayjj: yeh, I'm just suggesting we make it settable as a (n)make parameter..... | 15:24.15 |
| rayjj | they don't even have to edit imainarg.c since we use #ifndef | 15:24.36 |
| kens | FWIW I htink there was a mistake made when the transparency methods were added, its clear fomr the older code that device mthods should *NEVER* be NULL, and gx_fill_in_procs() sets all the methods to defaults, even if all the defaults do is throw an error and print a message. THe transparency handling doesn't work like that andf I htink it should. THere are probably other methods that need addressing similarly | 15:24.49 |
| rayjj | chrisl: XCFLAGS='-DGS_LIB="XXXX"' | 15:25.20 |
| kens | WHen I getthis all working I may fix that as well | 15:25.23 |
| chrisl | rayjj: fair enough..... | 15:25.31 |
| rayjj | has not tested that | 15:26.01 |
| kens | I thikn we should put warnings in the documentation for noth ROM file system and GS_LIB that later insatallations may have unexepcted side effects unless action is taken to set GS_LIB to something unique | 15:26.40 |
| | I know nobody reads the documentation, but at least we could point to it later | 15:27.09 |
| rayjj | kens: I agree that there shouldn't be NULL procs left after fill_in_procs laying around for the unwary | 15:27.09 |
| kens | raytjj there are lots :-( | 15:27.18 |
| | rayjj^^ | 15:27.22 |
| | fill_rectangle is deliberately NULL though and documented as such | 15:27.35 |
| | its filled in by gdev_alloc_buffer | 15:27.48 |
| chrisl | I still think it should be set to a default..... | 15:28.11 |
| kens | chrisl I could look at doing that, to me it would make sense as it would avoid us having to check for NULL methods | 15:28.32 |
| | gdev_prn_allocate_buffer can check for it being the default before overriding it, there are other places that do similar things | 15:29.10 |
| chrisl | kens: yeh, as I said the other day, it seems clear to me that the original intent was that it should never be required to check if a method is null before calling it | 15:29.30 |
| rayjj | I agree with chrisl. If we want to test if it is set to 'gs_no_fill_rectangle', or call it to see if it returns "gs_error_Fatal" that's fine | 15:29.33 |
| kens | I'll add that to my list of things to do when tidying up. | 15:29.56 |
| rayjj | kens: no rush. | 15:30.08 |
| | what we need is an OCD programmer to go through and tidy up everything ;-) | 15:30.39 |
| kens | I've found *so* many things in the device code as it stands that need addressing, some of tehm I've had to do just to get my code to work | 15:31.10 |
| rayjj | none of the OCD folks I know do software | 15:31.14 |
| | I assume our meeting is over (at least in the U.S. -- the UK folks still have 1/2 hour to go ;-) ) | 15:33.40 |
| chrisl | Oh, I meant to ask if anyone had anything to say about the GNU readline stuff in the docs..... | 15:34.18 |
| kens | Take it out! :-) | 15:34.27 |
| chrisl | I think that is almost certainly going to happen | 15:35.05 |
| rayjj | concurs with ken | 15:35.08 |
| kens | needs coffee before tackling the next round of my device bugs. | 15:35.49 |
| chrisl | rayjj: the only reason I didn't remove it today was because I know nothing of the history of it | 15:35.56 |
| kens | Does anyhone remember back to 6.0 ? | 15:36.19 |
| chrisl | Does anyone who remembers 6.0 actually care?? | 15:36.46 |
| kens | I doubt anyone cares about this anyway :@) | 15:36.59 |
| | Of course, after you remove it, the one person in the world who relies on it will file a bug report | 15:37.21 |
| chrisl | I don't think the code exists any more, at least, not our current code | 15:38.10 |
| kens | More reason to kill the docuemntation | 15:38.30 |
| chrisl | My reading of that section is: "we killed it in 6.0 because it didn't work, if any one feels inspired to sort it out, then have at it". Clearly, no one has...... | 15:39.23 |
| kens | Yep, I'm guessing nobody cared then, and even fewer people care now | 15:39.42 |
| rayjj | chrisl: in the Halloween spirit, get out the chainsaw | 15:39.45 |
| | anybody that wants it can get it from the repo | 15:40.30 |
| chrisl | rayjj: I think I prefer the axe - more visceral...... | 15:40.35 |
| rayjj | I have to run something over to the school. bbiab. | 15:42.02 |
| maslen | Is it possible to grab the positional text from a PDF and add it to another PDF in render mode 3 (invisible) with ghostscript ? | 17:18.43 |
| Robin_Watts_ | maslen: Not trivially, no. | 17:19.29 |
| kens | Technically anything is possible. How much effort are you prepared to go to, and how good are you at PostScript programming ? | 17:19.30 |
| | s/anything/almost anything/ | 17:19.58 |
| maslen | I'm willing to go through _some_ effort, but I know nothing about PS programming | 17:20.06 |
| Robin_Watts_ | maslen: Then abandon all hope. | 17:20.29 |
| maslen | Oh well :( | 17:20.33 |
| kens | Then you would first have to lear to program in PostScript, unless you are very masochistic, I would expect that to be much more effort than you want to go to | 17:20.44 |
| maslen | I was hoping for something that could just take coordinates and a string and write the text there :( | 17:21.21 |
| kens | You have top consider fonts as well | 17:22.49 |
| | The font in the original PDF may not be present in the second PDF, even if it is present, it may bve a differently encoded subset | 17:23.22 |
| maslen | I don't have to worry about that, as my plan is to use render mode 3 | 17:23.46 |
| kens | Presumably you want ot do this so that the text can be searched for. If you don;t use the same font, the spacing will be wrong | 17:24.20 |
| | So a search will highlight the wrong text | 17:24.33 |
| maslen | Oh :( | 17:24.47 |
| kens | There are a number of other problems to consider as well, such as the fact that you will have to interrupt the PDF interpreter after processing the page you want to insert the text, then draw the new text you want (and remember that PostScript doesn't have render mode 3 so you need to execute the same magic as Ghostscript's PDF interpreter to get that to work), then carry on processing the remaining page(s) | 17:26.17 |
| | Essentially what you are describing is a hard task | 17:26.28 |
| | At least, to do it properly | 17:26.47 |
| Robin_Watts_ | If I had to do it, I'd do it using mupdf and the new filter stuff. | 17:26.57 |
| | but even then I'd expect it to be hard. | 17:27.10 |
| kens | That would probably be easier, but you still have the problem with getting the info from the first file (presumably the etxt extraction would be the wya to go here) and getting the correct font selected | 17:27.29 |
| maslen | Hmm | 17:27.47 |
| kens | At least with both GS and MuPDF you can get the text, font name, and size extracted easily enough | 17:28.03 |
| maslen | What if I were to discard the original text data and attempt to 'regrab' it from an OCR ? | 17:28.12 |
| kens | Oh, and position | 17:28.12 |
| Robin_Watts_ | kens: I could do it using text extraction, yes, but I was thinking of filtering everything except the text content out. | 17:28.21 |
| maslen | Would that make the positioning of the OCR'ed values significantly easier? | 17:28.28 |
| Robin_Watts_ | at the operator level. | 17:28.28 |
| kens | : YRo yes, there are multiple ways to skin a cat, I was looking to minimise new code :-) | 17:28.56 |
| | maslen : You could do it (I suppose) by drawing each character individually at a specific location (which might defeat text searches for words, if the characters are far enough apart) | 17:29.48 |
| maslen | Hmm | 17:30.11 |
| | I'm not worried about searching as much as copying and pasting | 17:30.32 |
| kens | Getting the text, position, size and font name aren't so hard, adding them to another document so that they line up with an image, so that you cna search and have the highlight correct is another matter. Copying and pasting is the same problem, if the spacing isn't correct you may end up highlighting (say) ABC from the imager, but the text is closer spaced and you actually selcted ABCD | 17:31.39 |
| maslen | I see. | 17:32.11 |
| kens | In fact its really *more* important for copy/paste that the highlighted area match, because people will forgive some slop when searching | 17:32.18 |
| | But if they think they are highlightring ABC they'll be cross of they get more (or less) text | 17:32.41 |
| maslen | Is there an intelligent way to maybe just include the text in some arbitrary location, without supporting searching or copying, so that future text extraction could give you something useful ? | 17:33.13 |
| kens | I'd use something like Ghostscript or MuPDF to do the text extraction, that wil give you text, font name, size and locvation for each block of text. You can then use that ssame information to add the text to another document. If the font isn't present then a substitute will be used, but if all you care about is extractio, that's not a problem | 17:34.40 |
| | However, note that it is not 100% guaranteed that you cna extract *any* meaningful text from an arbitrary PDF file. | 17:35.05 |
| maslen | extraction I have down; it's putting it back in afterwards that's hard | 17:35.06 |
| kens | Without OCR | 17:35.11 |
| maslen | Understood. | 17:35.18 |
| | It all depends on the source file | 17:35.29 |
| kens | Indeed, not all PDF files have sufficient information to get 'text' out | 17:35.51 |
| | Once you have the text you want, you could turn it into PostScript, then define a custom EndPage procedure that reads and interprets that PostScript at the end of a defined page number. Then if you run it through GS you would end up with the text added. | 17:36.43 |
| kens | has to go, need to cook dinner. | 17:36.57 |
| | Goodnight all | 17:37.01 |
| maslen | Good night | 17:37.04 |
| | (I have no clue how to do any of that) | 17:37.18 |
| mvrhel_laptop | hi fredross-perry | 17:55.15 |
| fredross-perry | hey michael | 17:55.30 |
| mvrhel_laptop | how are things going? | 17:55.37 |
| fredross-perry | well. Iâve got a bunch of file/save as stuff working. Just a few things left, then maybe I should start looking at a Windows build. | 17:57.19 |
| mvrhel_laptop | that would be great | 17:57.26 |
| fredross-perry | good deal | 17:57.34 |
| | can you tell me about Intents? | 17:57.46 |
| mvrhel_laptop | so, are you able to use visual studio to do the windows build? | 17:57.48 |
| | oh yes. so the intents are needed for the conversions to PDF/A | 17:57.59 |
| | and PDF/X | 17:58.04 |
| fredross-perry | Right. Intents are still on my plate. | 17:58.21 |
| mvrhel_laptop | so if you look at my code, you should see them used in those cases | 17:58.23 |
| | they are ICC profiles | 17:58.30 |
| | so you would allow *.icm or *.icc file types to be selected for these | 17:58.56 |
| | and then I believe the path is included in the call to ghostscript in doing the conversion to pdf/A or pdf/X | 17:59.31 |
| fredross-perry | It might be nice to wrap that into the save process somehow. | 17:59.37 |
| mvrhel_laptop | yes, that is a possibility | 18:00.09 |
| fredross-perry | regarding WIndows, I thought I might try not VS, but Qt, which would require a g++-built version of mupdf libraries. I was able to do that for 32-bit, maybe I can for 64-bit as well. | 18:00.44 |
| mvrhel_laptop | so, is there a good reason to avoid using VS on windows? | 18:01.19 |
| | debugging for us would be a lot easier with VS for the future | 18:01.39 |
| | I am going to be very curious how the QT windows compares to the native app | 18:02.05 |
| Robin_Watts_ | I'm confused. I thought mvrhel_laptop's gsview already ran on TIFKAM and win32 ? | 18:02.45 |
| mvrhel_laptop | we wont need VS to do that comparison, but if we decide to go with the QT version for windows, having it build in VS would really be ideal | 18:03.13 |
| fredross-perry | Robin: it does, but we were talking about 10 days ago how it might work to make a Windows build of the Qt-based version I have. One advantage might be a single consistent UI. | 18:03.37 |
| mvrhel_laptop | Robin_Watts_: at the staff meeting henrys and I were talking about not having 2 projects but seeing if the QT version was OK on windows | 18:03.38 |
| Robin_Watts_ | Ok. | 18:03.51 |
| mvrhel_laptop | it stinks a bit from the stand point that I wrote a lot of code that is going to the trash heap in that case | 18:04.00 |
| Robin_Watts_ | And QT won't work with Visual Studio? | 18:04.00 |
| mvrhel_laptop | yes it should | 18:04.05 |
| | we did it at my previous job | 18:04.15 |
| | when we built a viewer for XPS | 18:04.22 |
| Robin_Watts_ | Will QT work for TIFKAM apps ? | 18:04.31 |
| mvrhel_laptop | I had to look up TIFKAM | 18:04.58 |
| fredross-perry | But if you build with VS youâll have two projects anyway, just sharing most of the source code. | 18:05.05 |
| mvrhel_laptop | so, it will not work with TIFKAM | 18:05.08 |
| | that is a good point Robin_Watts_ | 18:05.21 |
| | I do share code between the windows store app and the desktop app | 18:05.39 |
| Robin_Watts_ | So it seems like we're going to be keeping your gsview around for TIFKAM anyway. | 18:05.55 |
| mvrhel_laptop | that may be an argument for leaving windows as it is | 18:05.55 |
| | if its easy to do, (like a couple days) I would say lets see how the QT version compares on windows | 18:06.33 |
| | if its going to be weeks, then I am not sure its worth fooling with. | 18:06.58 |
| | but we should let henrys decide | 18:07.09 |
| | is there a way for me to get what you have to use on ubuntu fredross-perry ? | 18:08.07 |
| fredross-perry | Iâll zip something up and send it to you tomorrow (my laptop for that work is at my office, and I am not). | 18:08.48 |
| mvrhel_laptop | fredross-perry: ok great. thanks | 18:08.59 |
| henrys | tifkam where does he come up with these things ? :-) | 18:09.10 |
| mvrhel_laptop | hehe. | 18:09.19 |
| Robin_Watts_ | TIFKAM is from theregister | 18:09.32 |
| fredross-perry | wikipedia is your friend (tifkam) | 18:09.40 |
| henrys | got it in the urban dictionary but I was curious what Robin_Watts_ was reading to come across that. now I know. | 18:10.11 |
| fredross-perry | Itâs in the dictionary right after TAFKAP | 18:10.45 |
| mvrhel_laptop | :) | 18:12.33 |
| Robin_Watts_ | henrys: Originally it was to be called Metro. then it was to be "Modern UI", then it was to be called "Windows Store App UI". | 18:13.03 |
| | But then they started to sell win32 apps on the store as well, so god knows what the official term is now. | 18:13.24 |
| | It's a typical microsoft clusterfuck. | 18:13.31 |
| mvrhel_laptop | yes. | 18:13.41 |
| | just wait until they start adding 2014, 2015, 2016 onto the name | 18:14.02 |
| Robin_Watts_ | "Clusterfuck" apps. I like that. It has a certain ring to it. | 18:14.08 |
| | Clusterfuck 2014 Team Edition | 18:14.57 |
| henrys | mvrhel_laptop: we probably should be leary of supporting anything that starts off with TIFKA | 18:15.00 |
| mvrhel_laptop | hehe | 18:15.00 |
| henrys | mvrhel_laptop: really up to you. I'd lean toward just QT but not strongly. | 18:16.57 |
| fredross-perry | you have to capitalize the âFâ: ClusterFâk | 18:16.57 |
| mvrhel_laptop | well I would like to see how they compare performance wise | 18:17.19 |
| fredross-perry | Iâd like to try a 64-bit Qt build for Win soon then we can compare. | 18:18.02 |
| mvrhel_laptop | sounds good | 18:18.10 |
| henrys | mvrhel_laptop: yup fair enough | 18:18.25 |
| | mvrhel_laptop: now I find out a financial advisor is handling all this medical stuff. Oh god... I'm going to have to fly to china if I have a medical emergency. | 21:07.05 |
| mvrhel_laptop | :) hmm I guess the switch is happening in a couple days | 21:07.45 |
| henrys | I was told I could send in my forms sealed and treated as if I were mad. | 21:08.29 |
| | yeah john why don't we have a few beers and laugh over the wives prescriptions... has everyone gone crazy. | 21:09.21 |
| | ? | 21:09.24 |
| mvrhel_laptop | :) | 21:09.32 |
| | yes. I don't recall doing all this the first time | 21:09.57 |
| avih | dinamic: hmm... i think the crash bug comes from the implementation of array.aplice. when i replaced it with my own implementation, poof... no more crashes at all despite stressing everything pretty hard | 22:23.45 |
| | splice* | 22:23.52 |
| | Forward 1 day (to 2014/10/29)>>> | |
IRC Logs