| | <<<Back 1 day (to 2015/01/20) | 20150121 |
| mvrhel_laptop | ok. I think I see what is going on with this particular xpswrite issue. the path geometry has multiple moves in it. we can't pack that all in a single data path structure but it must go in a path geometry structure | 00:46.15 |
| | should have a fix tomorrow. tonight is filled with school meetings | 00:46.38 |
| Robin_Watts | move line move line move line ? | 00:46.54 |
| | or move move move line ? | 00:46.58 |
| mvrhel_laptop | move line line line move line line line move line line ...... and on and on and on and on | 00:47.13 |
| | mupdf screws this one up too | 00:47.25 |
| Robin_Watts | mvrhel_laptop: Why is that not a single path? | 00:47.32 |
| mvrhel_laptop | the pdf source was created this way | 00:47.45 |
| | do you want me to send you the file | 00:47.53 |
| | its crazy | 00:47.56 |
| | I have it cut down | 00:48.04 |
| Robin_Watts | I am tempted to say yes, but I mustn't get distracted. | 00:48.11 |
| mvrhel_laptop | hehe | 00:48.13 |
| Robin_Watts | Could you open a bug and stick it on there? | 00:48.19 |
| mvrhel_laptop | yes. will do | 00:48.24 |
| Robin_Watts | Thanks. | 00:48.28 |
| mvrhel_laptop | Robin_Watts: if you get bored. http://bugs.ghostscript.com/show_bug.cgi?id=695792 | 00:53.23 |
| Robin_Watts | mvrhel_laptop: Ta. | 00:53.44 |
| mvrhel_laptop | brb | 00:53.49 |
| rayjj | tomorrow night is my school meeting night. My youngest little guy is going away for a WHOLE WEEK and the meeting is Wed night. In the meantime tomorrow AM are my older kids' Finals. My son has 4 the same day and because Chemistry is a "before school" (0 period) class, he has to get in extra early :-( | 01:00.32 |
| | can you imagine taking a chemistry final at 6:15 AM as a high schooler ? | 01:01.17 |
| mvrhel_laptop | 6:15am exam in high school? crazy | 04:36.36 |
| Robin_Watts | Digit_: You were asking about linearised PDF support in MuPDF. | 10:06.01 |
| | It's there in the main branch on master. | 10:06.22 |
| | s/on master/in git/ | 10:06.40 |
| tor8 | hello | 10:09.26 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 10:09.26 |
| tor8 | Robin_Watts: ghostbot needs a poke... | 10:09.26 |
| | or my internet connection does... | 10:09.35 |
| Robin_Watts | tor8: Digit asked me on a private tab :) | 10:10.47 |
| tor8 | Robin_Watts: ah. that explains the lack of log :) | 10:10.58 |
| | Robin_Watts: could you take a peek at zeniko's xref-fixes? the non-xref ones LGTM and should be merged before I go crazy with API cleanups... | 10:12.05 |
| Robin_Watts | ok. | 10:12.25 |
| tor8 | zeniko is going to kill me... but I've had it with the inconsistency of drop/free naming and which functions take a fz_context and which don't | 10:13.08 |
| | so I'm going on an API cleaning spree | 10:13.18 |
| | coming back to the core code after all my excursions with MuJS and EPUB show the necessity :( | 10:13.56 |
| Robin_Watts | tor8: Assuming they pass cluster tests, yeah, look good. | 10:16.23 |
| Digit_ | Robin_Watts: Thanks for the info about linearised pdfs. is there anything documented or do i have to go through the muPDF code? I use it on android. | 10:36.09 |
| Robin_Watts | Digit_: See docs/progressive.txt | 10:36.29 |
| | It is not currently hooked up for android. | 10:36.43 |
| Digit_ | Robin_Watts: Thx i will have a look | 10:44.26 |
| | Robin_Watts: You mean its not currently working in the android version? | 10:50.56 |
| Robin_Watts | Digit_: Indeed. The Android code gets its data from either a block of memory or an input stream. | 10:53.28 |
| | and the input stream case has not been updated to handle directed requests. | 10:53.49 |
| | It's not a huge job. | 10:54.02 |
| Digit_ | Robin_Watts: That i can do, no problem, i just wonder how i can request single pages from the server. But i have not read the progressive doc yet | 10:58.03 |
| Robin_Watts | Digit_: Have a look at curl_stream.c and curl_stream.h | 10:58.21 |
| | That's how it's implemented using curl. | 10:58.27 |
| | Digit_: You can't request 'single pages' from the server. | 10:59.23 |
| Digit_ | ok thanks you helped me lot | 10:59.32 |
| Robin_Watts | You can open a document and then preferentially get the data for a given page before the rest of the file. | 10:59.53 |
| | np. Let us know how you get on. | 11:00.05 |
| Digit_ | yepp i will do. :) | 11:00.21 |
| Robin_Watts | tor8: The regression mujstest's have been very unhappy ever since 026e27be430c5d1dca82f087ed1dc1a594232b70 | 12:50.19 |
| tor8 | Robin_Watts: hmm. I think whatever it was unhappy about is fixed in the latest mujs | 13:01.29 |
| Robin_Watts | The latest mujstest results from the cluster still show the faults. | 13:03.40 |
| tor8 | Robin_Watts: we never merged the strcpy fixes. try the commit on tor/master? | 13:05.04 |
| Robin_Watts | Urm... tor/master isn't strcpy fixes. | 13:09.48 |
| | oh, sorrry, ignore me. | 13:10.10 |
| | yeah. go ahead and push that. | 13:10.18 |
| tor8 | it's an update of the mujs submodule | 13:10.21 |
| Robin_Watts | hopefully that'll solve it. | 13:10.28 |
| tor8 | pushed. | 13:10.43 |
| Robin_Watts | tor8: compile fail from the cluster for the latest non js build. | 13:32.25 |
| | source/pdf/js/pdf-jsimp-mu.c:187:4: error: too few arguments to function 'js_newuserdata' | 13:33.16 |
| | (in 4 places) | 13:33.23 |
| tor8 | Robin_Watts: gah. merge errors :( | 13:46.03 |
| | force push? | 13:46.33 |
| | there's a fix on tor/master that I can push, but if we want clean history I can squash and force push | 13:49.15 |
| Robin_Watts | tor8: I say force push. | 14:32.46 |
| | Tell me when you've done, and I'll prod the cluster. | 14:33.07 |
| | oh, you've pushed already. we'll live with that :) | 14:38.01 |
| rayjj | morning, all | 14:46.05 |
| Robin_Watts | morning, rayjj | 14:46.21 |
| tor8 | Robin_Watts: yeah, I didn't want to leave master sitting broken too long | 14:50.33 |
| | Robin_Watts: looks like the mujstest stuff has stopped crashing | 14:50.52 |
| Robin_Watts | it does. | 14:51.01 |
| mvrhel_laptop | marcosw: do you have any other xpswrite issues other than CATX0988 which is bug http://bugs.ghostscript.com/show_bug.cgi?id=695790. This particular clip path for the image is poorly constructed. mupdf also does not render it correctly. I don't want to spend a ton of time on it right this sec, but if you had something else since you did say "images" in the bug | 16:52.43 |
| henrys | oh wow exercise doesn't even protect you from sitting: http://www.cbsnews.com/news/too-much-sitting-raises-risk-of-death-even-if-you-exercise/ | 16:56.43 |
| henrys | has the URW fonts - they claimed to send them last email I sent ... | 16:57.12 |
| | apparently standing doesn't protect you from the flu, though. | 16:57.48 |
| | they just sent ttf's but there shouldn't be delay in getting type 1's. | 17:00.01 |
| Robin_Watts | http://www.cad-comic.com/cad/20150102 | 17:00.09 |
| mvrhel_laptop | funny | 17:05.04 |
| henrys | Robin_Watts, mvrhel_laptop : while you guys are together, I guess we are to acquire the ETS patent. Miles is taking it off Raph's hands for some reason. Do we want to do any work with this? I know a math student working on his phd looking for an internship. He's done image processing. | 17:08.03 |
| mvrhel_laptop | henrys: I don't know how much interest customer wise there is for this stuff. | 17:09.36 |
| | Two issues are going against us | 17:10.07 |
| | One is that dot sizes have gotten so small that the HT algorithm has become less critical | 17:10.33 |
| | The other is that there is a fair amount of code floating around for someone to cobble together something decent | 17:11.45 |
| henrys | Yea the only interest I've seen was from that "Porter" character... not sure what became of that. | 17:11.49 |
| Robin_Watts | In order for ETS to be saleable, we need to have a compelling demo of it. At the moment we say "Wow! Look, we've got this really cool technology! If you tune it to your printer it'll look great." We need to actually be able to show printouts with/without our stuff. | 17:11.54 |
| mvrhel_laptop | Another good point | 17:12.11 |
| Robin_Watts | So, an intern that could actually do that tuning for a given popular printer would be worthwhile, I think. | 17:12.31 |
| | And to document the process he went through. | 17:12.56 |
| mvrhel_laptop | Yes. Especially if they worked with the customer I mentioned in the private message henrys | 17:13.56 |
| Robin_Watts | If we're not prepared to invest at least that much time/effort/money into it, then buying the patent is a waste of time. | 17:14.04 |
| henrys | mvrhel_laptop: and you think using ETS would result in something better (if tuned) that what that customer uses now. | 17:16.34 |
| | ? | 17:16.35 |
| | s/that/than | 17:16.53 |
| kens | I'm finally seeing a small hint of light with the mswinpr2 device. Looks like it changes its dev->color_info and the parent doesn't update from it. Need to find out where that happens. And with that, I've had enough for the day. Goodnight folks | 17:17.55 |
| mvrhel_laptop | henrys: It is possible. They are they type to notice such things to this level. They have expressed interest on each visit. The issue there is a certain person who I believe has issues working with us. | 17:17.59 |
| rayjj | henrys: mvrhel_laptop: Robin_Watts: that's what Raph did. He tuned it for an Epson printer (now obsolete) generated output from Epson's driver vs. ETS and Scott went around showing it. | 17:20.57 |
| | The problem is that the $$$ in licensing screening was so low. | 17:21.16 |
| mvrhel_laptop | right. this is not going to be a huge money maker | 17:21.27 |
| Robin_Watts | rayjj: Right, and that's great, but a) that printer is obselete, and b) people need to be told "this is how you tune ETS for a printer" | 17:21.50 |
| | a step by step, idiot proof guide. Ideally simple enough so even I could follow it. | 17:22.08 |
| mvrhel_laptop | Yes that would be nice to have | 17:22.34 |
| Robin_Watts | without it, I can't see how we'll ever get a customer to bite. | 17:22.54 |
| rayjj | Robin_Watts: that's the problem is that the tuning is a bear and you are never sure you are "done". | 17:23.03 |
| Robin_Watts | rayjj: Right. I'd imagine that it'd be a series of "print this out", "measure the results with a colorimeter to generate this table" etc. | 17:24.00 |
| rayjj | Robin_Watts: that and in order to do it right you need to try it on several printers of the same type since tuning for just one can be misleading | 17:24.09 |
| | manufacturing differences | 17:24.17 |
| Robin_Watts | rayjj: And paper types. | 17:24.23 |
| | I'm not arguing that it's a simple problem. Just that we should attempt to reduce it to the simplest possible problem for our customers to solve. | 17:25.19 |
| rayjj | Robin_Watts: I just doubt that the customer $ are there -- and I think Scott's given up on it as well. | 17:26.56 |
| Robin_Watts | rayjj: If we believe the patent is worth paying for, then we have to believe it's worth investing the money in getting the work done. | 17:27.41 |
| | Otherwise, why buy the patent? | 17:27.46 |
| rayjj | Robin_Watts: I have no idea why Miles wants to buy the patent | 17:28.02 |
| henrys | rayjj: that's not true - miles may be just helping out raph for some other reason. | 17:28.10 |
| Robin_Watts | How expensive is an intern? | 17:28.14 |
| henrys | sorry that should have been to Robin_Watts not rayjj | 17:28.39 |
| Robin_Watts | right. | 17:28.46 |
| | henrys: well, assuming he's buying it for business reasons, we have to believe... | 17:29.07 |
| | IMAO, without going through that process, spending any more time on ETS (either development or sales) is a waste of effort. | 17:29.50 |
| henrys | but we all agree that we can't dismiss the technology as obsolete (1999) or problematic without further investigation. | 17:31.10 |
| | ? | 17:31.11 |
| rayjj | how many more years on the patent ? 1? 2? | 17:31.55 |
| henrys | mvrhel_laptop brough up the point with dot sizes today there may not be anything worth while here. | 17:32.13 |
| | http://www.google.com/patents/US5917614 | 17:33.12 |
| mvrhel_laptop | As far as buying the patent, having another patent in the Artifex queue of patents is not always a bad thing. It looks good for the company and this may have been an easy one to get and it is related to what we do | 17:33.44 |
| rayjj | henrys: yes, and mostly is is printer manufacturers that have the incentive and resources. RIP guys don't really have the resources to spend time "tuning" ETS for printers (IMHO) | 17:33.59 |
| mvrhel_laptop | He has not been paying the maitntenance fees | 17:34.53 |
| | The patent has expired | 17:35.01 |
| | Not sure why miles would buy it now | 17:35.25 |
| | Better let Miles know before he signs the check | 17:36.06 |
| rayjj | mvrhel_laptop: that is a very good question (Fee status: lapsed) and filed in 92 | 17:36.10 |
| mvrhel_laptop | It expired in 2003 | 17:36.30 |
| Robin_Watts | So it's utterly worthless. | 17:36.38 |
| mvrhel_laptop | yes | 17:36.45 |
| henrys | okay let me check what miles is up to. | 17:37.18 |
| | I am sure we have licensed that stuff and called it "patented" hah... | 17:40.20 |
| Robin_Watts | mvrhel_laptop: 2003? | 17:43.36 |
| | From 1992, 20 years would be 2012 ? | 17:43.57 |
| henrys | Lapse for failure of maintenance 2003 | 17:44.03 |
| mvrhel_laptop | That is when the last maintaince fee was due | 17:44.08 |
| Robin_Watts | oh, right :) | 17:44.09 |
| rayjj | two new (old) customer bugs (apparently they were from cust 582 and we didn't know they were) | 17:49.13 |
| | :-( | 17:49.32 |
| | at least they aren't a P1 customer | 17:51.06 |
| chrisl | rayjj: I have 582 listed under "PERMANENTLY NON-SUPPORTED CUSTOMERS" | 18:03.01 |
| rayjj | chrisl: you are right. I didn't notice that. | 18:03.35 |
| chrisl | rayjj: possibly worth mentioning to Miles they've been in touch? | 18:03.52 |
| rayjj | probably so since David thinks this should be treated as a "paid user report" | 18:04.32 |
| | chrisl: he was cc'ed on the original from David and my reply that I cc'ed to support. | 18:05.07 |
| chrisl | rayjj: Oh, well, we should leave it with Miles, then. Assign the bugs to him! | 18:05.46 |
| | Have to go..... | 18:07.50 |
| rayjj | holy cow. That "endless" PDF at 720 dpi created a 7.5Gb clist. I stopped the 1440 after it was up to 22 Gb. At 720 it takes 180 seconds to write the clist, and only 80 seconds to render | 19:11.44 |
| | At 720 dpi I can process in page buffer mode (-dBufferSpace=1900m) and it finishes in 150 sec | 19:20.03 |
| | back to plib work | 19:20.20 |
| mvrhel_laptop | Hi Robin_Watts. There are two commits on my mupdf repos when you get a chance to take a look | 21:22.01 |
| | one is a fix for an exception that was not getting caught. the other is a fix for an issue in the display list cache | 21:22.25 |
| | both gsview related obviouslyl | 21:22.39 |
| rayjj | Robin_Watts: I've found the plib device issue, and it stems from a fix commit c4357bef back in Nov 2013. You fixed some segfault(s) but the plib device, which isn't tested, was broken. The segfault was then masked by the BandHeight check that just caused us to exit with rangecheck | 23:21.56 |
| | kens: Robin_Watts: (for the logs) One of you please review my commit that restores the plib device to working.http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=ae95b8aaa03b846a939bee025774f0e0f331ce4d | 23:24.31 |
| | As I tried to explain in the log message, the mdev->line_ptrs was not being set. When NULL was passed into the setup_buf_device, the plib device would allocate them and set the mdev->line_ptrs (which caused other problems when the device was finalized), but if a pointer to the area for the line_ptrs was passed in, mdev-line_ptrs was not set (as it was in gdev_mem_set_line_ptrs). | 23:30.45 |
| Robin_Watts | rayjj: Looks plausible. Thanks. | 23:58.00 |
| | Forward 1 day (to 2015/01/22)>>> | |
IRC Logs