| | <<<Back 1 day (to 2015/09/21) | 20150922 |
| rsc | Robin_Watts: I do not know what kind of documents I have. So JPEG or PNG decision makes only sense if I know the kind? | 07:24.37 |
| chrisl | rsc: Generally you don't want to use lossy formats if you have any text or vector drawing in a file | 07:27.26 |
| rsc | chrisl: well, it's just a preview of a PDF | 07:27.54 |
| chrisl | rsc: depends what you mean by "preview"..... | 07:28.27 |
| rsc | chrisl: I shall generate something like a larger thumbnail to give some impression about the document (imagine it as ~ 400x400 pixel image) | 07:32.17 |
| chrisl | rsc: well then, I'd think JPEG will be fine. OTOH, the likely difference in size between a PNG and JPEG of that size, personally, I'd probably use PNG | 07:33.50 |
| rsc | Thanks! | 07:39.34 |
| chrisl | No worries. | 07:39.49 |
| Vladyslav | Hi all! I have a problem with mupdf again. We are write the PDF reader now. We use DirectWrite for rendering pages and we take info about font using mupdf fz_font. And when I get ft_buffer from "Helvetica-Bold" font, it always NULL. thanks for any help | 13:43.30 |
| | someone can help me? | 13:58.55 |
| Robin_Watts | Vladyslav: Hi | 13:59.15 |
| | You're writing a PDF reader using MuPDF? For what platform? | 13:59.32 |
| jogux | DirectWrite => some kind of Windows at least. | 14:06.32 |
| kens | DirectWrite needs (IIRC) Windows 7 or better | 14:11.57 |
| | Its used for text rendering I believe | 14:12.21 |
| | Oh apparently I'm slightly wrong, it was shipped with Vista as well | 14:12.52 |
| rayjj | morning, all. | 14:26.53 |
| | Are we having a meeting ? | 14:27.01 |
| kens | assumes so | 14:27.07 |
| Robin_Watts | I would assume not. We generally don't the weeks before/after an in-person meeting. Or at least, it's not compulsory. | 14:27.36 |
| rayjj | hopes not | 14:28.12 |
| | but I'm here just in case | 14:28.39 |
| mvrhel_laptop | I am guessing we dont | 14:28.56 |
| kens | well henrys was taslking in terms of a SO Skype meeting at least, either today or Thursday | 14:29.00 |
| marcosw | morning | 14:30.02 |
| Robin_Watts | mvrhel_laptop: For anyone that's bored, I put my attempts at trapping code online. | 14:30.22 |
| mvrhel_laptop | oh yes. I was going to look at that | 14:30.32 |
| | I have been looking a bit at the literature on the subject. | 14:31.09 |
| Robin_Watts | It's dead simple stuff; it runs through components from dark to light and looks for which ones 'fall off a cliff' if that plane is displaced. | 14:31.10 |
| | If such a cliff edge is detected, then lighter colorants are pulled in underneath it. | 14:31.55 |
| kens | I looked at the output but haven't felt awake enough to look at the code yet | 14:32.12 |
| mvrhel_laptop | seems reasonable. | 14:32.18 |
| Robin_Watts | Consequently it results in color bleed, which can upset color correctness. I'd be interested in any suggestions, or better solutions. | 14:32.34 |
| fredross-perry | whats the probelm that trapping is meant to solve? | 14:33.19 |
| tor8 | Vladyslav: (for the logs) the ft_buffer field of fz_font is private, and is only used to keep track of reference counts in certain use cases. | 14:33.27 |
| mvrhel_laptop | to try to reduce the visual effects from misalignment of color planes | 14:33.52 |
| Robin_Watts | fredross-perry: When you print stuff, you can sometimes get misregistration of the different colors. | 14:34.06 |
| rayjj | Robin_Watts: have the relevant trapping patents expired ? | 14:34.07 |
| Robin_Watts | rayjj: I am unaware of trapping patents. | 14:34.20 |
| mvrhel_laptop | I am sure there are a pile of them | 14:34.30 |
| Robin_Watts | That's not to say they don't exist, just that I don't know of them. | 14:34.32 |
| rayjj | Robin_Watts: but the results look reasonable | 14:34.33 |
| tor8 | Vladyslav: if you want the underlying font data, you'll need to either ask freetype (using the ft_face field) or change mupdf to also keep a pointer to the data when creating a fz_font | 14:34.37 |
| kens | rayjj I believe the vast majority of those relate to vector-based or display list style trapping | 14:34.40 |
| Robin_Watts | Henry mentioned trapping patents, but said that he thought they tended to be at vector level. | 14:34.52 |
| rayjj | unfortunately searching for trapping patents shows up mostly rodent trap patents :-/ | 14:35.01 |
| | Robin_Watts: no, the original trapping patents were raster based | 14:35.22 |
| mvrhel_laptop | most would be by xeros | 14:35.35 |
| | xerox | 14:35.38 |
| rayjj | the vector ones came later and are more likely to still be in force. | 14:35.48 |
| mvrhel_laptop | like this | 14:35.56 |
| | http://www.google.com.ar/patents/US8437045 | 14:35.58 |
| Robin_Watts | http://www.google.com.tr/patents/US20050012946 | 14:36.06 |
| mvrhel_laptop | and this | 14:36.25 |
| | http://www.google.com/patents/US20070236740 | 14:36.27 |
| Robin_Watts | mvrhel_laptop: My stuff works on contone, so that one doesn't apply. | 14:36.30 |
| mvrhel_laptop | oh I am not saying you are violating | 14:36.48 |
| rayjj | mvrhel_laptop: well, the first one isn't applicable since it works from the halftoned data | 14:36.49 |
| Robin_Watts | mvrhel_laptop: Indeed. I was just relieved to see that I don't think I am. | 14:37.12 |
| mvrhel_laptop | just saying that I am certain xerox has piles of patents on the topic | 14:37.36 |
| | as does HP | 14:37.40 |
| rayjj | and the 12946 is object based (not raster) | 14:37.55 |
| mvrhel_laptop | again. | 14:38.11 |
| | I did not say these were violations | 14:38.16 |
| rayjj | mvrhel_laptop: no, I know you didn't. | 14:38.34 |
| Robin_Watts | mvrhel_laptop: This was/is just a toy project that I worked on during the flight. If we pursue it further, then we should probably do a quick search. | 14:39.24 |
| rayjj | I thought the raster ones were scitex | 14:39.36 |
| kens | We looked into trapping when I was working for 5D and believed we would have to be careful for object/vector trappign but that bitmap based wasn't a problem | 14:39.39 |
| Robin_Watts | I dunno whether trapping is a useful feature to have in gs or not these days. | 14:40.15 |
| mvrhel_laptop | Jan Allebach who I have done some work with has this paper. He has done a pile of work in halftoning and was heavily funded by HP. He does very good work. https://engineering.purdue.edu/~mboutin/papers/color_trappingEI08.pdf | 14:40.24 |
| | Worthwhile to look at the references in the paper too | 14:40.50 |
| kens | Robin_Watts : my opinion would be that it would not be likely to make us much (if anythign) in new sales. | 14:41.08 |
| rayjj | Robin_Watts: it was requested along the way by printer companies or companies that do printer rips for printer companies. HP has trapping control in their PCL and Adobe PS has trapping stuff | 14:41.39 |
| | it's sort of a 'check off' item | 14:42.10 |
| mvrhel_laptop | Robin_Watts: it is likely he has a full length (not conference) paper on the topic | 14:42.21 |
| kens | rayjj it was really in vogue about 10-15 years back, I've not heard anyone discuss it seriously reecently | 14:42.22 |
| rayjj | it isn't needed for inkjet printers, but some laser printers seem to need/use it | 14:42.46 |
| mvrhel_laptop | right | 14:42.59 |
| kens | colour laser printers at least used to do multple passes over the media, moving the media back and forth could lead to registration errors, its possible that's been solved | 14:43.45 |
| rayjj | kens: it's much less of a problem with modern 'inline' laser engines. The old multi pass ones were pretty bad at registration. | 14:44.48 |
| kens | THha'ts what I thought | 14:44.59 |
| henrys | I was hoping we could do a "due diligence" patent search and then include Robin_Watts stuff in the gs release with documentation. | 14:45.05 |
| Robin_Watts | mvrhel_laptop: Ah, that paper attempts to detect and characterise edges. | 14:45.40 |
| | My code is much dumber :) | 14:45.45 |
| rayjj | but the multi pass ones were so slow that they are no longer competitive. When you can get an inline color laser for < $300 there isn't much point in the slower mode | 14:45.50 |
| | henrys: not THIS release, I hope | 14:46.42 |
| henrys | i.e. we don't need to do market analysis, just check it's okay legally and get it in a release. | 14:46.43 |
| mvrhel_laptop | It would be a good checkbox item to say that we have it | 14:47.23 |
| henrys | it's still critical in offset printing no? | 14:47.41 |
| rayjj | if we put it in gs, we should hook it into the trapping controls defined for PS and PCL | 14:47.41 |
| | henrys: yes | 14:47.55 |
| kens | Its always nce to have extra features, but it might commit us to future work if we're not careful | 14:47.59 |
| mvrhel_laptop | there could be worst things | 14:48.17 |
| rayjj | is it studio rip or lucid dream that does trapping (after rendering by gs) ? | 14:48.36 |
| Robin_Watts | especially as that work does not involve SOT. | 14:48.37 |
| | (oops, did I say that out loud?) | 14:48.45 |
| mvrhel_laptop | rayjj: the former | 14:48.53 |
| kens | I'm just wary that as cusotmer might start using it, then want stuff fixed/improved when we don' really ato do so | 14:49.01 |
| mvrhel_laptop | I think they tried to sell it to us at one point | 14:49.05 |
| Robin_Watts | kens: NRE :) | 14:49.13 |
| kens | Robin_Watts : yes, I'm not saying it can't be addressed, I just want us to be really careful about it | 14:49.34 |
| rayjj | mvrhel_laptop: OK. Didn't they also try and sell us a halftoning method ? | 14:49.42 |
| henrys | I'd rather mvrhel_laptop did the patent search in the interest of having separate eyes on it, but I know he's busy | 14:49.49 |
| mvrhel_laptop | rayjj: I think so. | 14:49.50 |
| | henrys: I can do that | 14:50.04 |
| kens | Prior exposure to trappign leads me to feel its the sort of problem where there is never a single 'correct' answer, so you end up applying heuristics, whcih can go on forever | 14:50.23 |
| mvrhel_laptop | kens: yes | 14:50.30 |
| | that is the type of problem it is | 14:50.37 |
| rayjj | This was back in 1996, so any patent preceded it: http://connection.ebscohost.com/c/articles/9610161336/screen-harlequin-sue-scitex-over-trapping | 14:51.39 |
| henrys | Right harlequin is my major concern. I was just talking to their VP of engineering and how happy we are to coexist in without too much competition ;-) | 14:53.44 |
| | s/in// | 14:54.28 |
| rayjj | patent http://www.google.com/patents/US5295236 mentions the method that Robin used in the 'prior art' using frame buffers for each colorant. That patent was 1991, so I don't think there is any patent still in force for raster frame buffer based trapping | 15:05.47 |
| Robin_Watts | I've just heard that my electrician is coming back tomorrow to do the final testing. | 15:09.06 |
| | This involves unplugging everything all around the house and testing lots of stuff, so I may not be online tomorrow. | 15:09.26 |
| rayjj | One of the first patents on automated trapping seems to be: http://www.google.com/patents/US4583116 (1986) | 15:09.40 |
| | Robin_Watts: oh, joy. | 15:09.50 |
| Robin_Watts | patents are 20 years from filing (at longest), so anything 1995 or earlier doesn't concern us, right? | 15:12.18 |
| rayjj | Robin_Watts: something like that. It used to be 17 years, I thought, but it got extended to 20. and I'm not sure if it's the filing date or the publication date | 15:13.42 |
| Robin_Watts | 20 years from filing. | 15:13.51 |
| | (says google) | 15:13.57 |
| mbor | hi! I'm trying to process a PDF using this command: https://gist.github.com/anonymous/9cd9a3e10565b41ef8ab. however, I get thousands of these errors: "+ ./base/gdevp14.c:1729: pdf14_put_image(): PDF14 device push/pop out of sync". here's the PDF: http://www.speedyshare.com/yC2cZ/coop-extra-midt-38.pdf. I'm using version 9.16. is this a bug or? | 20:34.47 |
| rayjj | dang. I forgot that to use --amend on a commit, so I ended up pushing two commits. I assume that it is too late to "squash" them ??? | 21:21.50 |
| | mbor: I recommend submitting a bug. We don't really do "live" bug investigations from IRC since we want to track bug/fixes in our bugzilla bug system | 21:23.16 |
| mbor | rayjj: will do. thx! | 21:24.23 |
| rayjj | that'll teach me to remember to do 'git logg -10' before pushing to origin (to make sure I don't have pending local commits that I really wasn't ready to commit. It would have shown me that I needed git -i rebase ... | 21:25.13 |
| | Robin_Watts: (or anyone else) would it be OK to git rebase locally to 'fixup' the previous commits, then push that ??? (or would that cause problems later)? | 21:26.15 |
| | mbor: thanks for using gs, and thanks (in advance) for the bug report | 21:27.11 |
| rayjj | just missed him :-( | 21:27.24 |
| | marcosw (for the logs): You'll be happy to know that I found the cause of the indeterminism with 09-40.PS | 22:09.55 |
| mvrhel_laptop | nice! | 22:10.05 |
| | what was it rayjj | 22:10.11 |
| | is that the one with the pattern get alpha bits? | 22:10.34 |
| rayjj | it was when 'num_repeats' in the ht_order was > 1. It wasn't initializing the entire threshold array | 22:10.50 |
| mvrhel_laptop | wow | 22:11.01 |
| | nice find | 22:11.15 |
| rayjj | mvrhel_laptop: it was with a screwy HalftoneType 16 that had num_levels=5441 with a 10x10 halftone array | 22:11.44 |
| mvrhel_laptop | I would have never found that | 22:12.02 |
| | looking at these numbers in the email that you sent in oct 17 rayjj | 22:12.22 |
| | they are quite good based upon what I had spoke with mq today | 22:12.35 |
| rayjj | the clist colorspace confusion issues are much harder to track down | 22:12.45 |
| mvrhel_laptop | I resent them to him to see why he never commented on them back then | 22:12.52 |
| rayjj | mvrhel_laptop: yeah, and we never heard back on any competitor's numbers back then, either | 22:13.23 |
| mvrhel_laptop | I doubt they will tell us what the competitor is doing. but I did get a little information | 22:13.53 |
| rayjj | but after company "T" sort of went dark, we didn't push further | 22:13.57 |
| | mvrhel_laptop: every bit you can get is great | 22:14.12 |
| | the thing is that we were just benchmarking the RIP step, and the memory bandwidth comes into play when actually running the entire print pipeline (as I know from Company K -- cust 532) | 22:15.40 |
| | so even with 1,200 ppm on text files for the RIP step, the overall throughput could be quite a bit less. | 22:16.44 |
| mvrhel_laptop | right | 22:16.58 |
| | tell that to marketing.... | 22:17.30 |
| rayjj | something is screwy with the cluster tests. I do a run and get very few differences 5 of 61318 non-pdfwrite but get "The following 66436 regression file(s) have started producing errors:". I run it a second time, and don't see any 'started producing errors" messages | 22:25.32 |
| | nor any error messages in the logs | 22:25.54 |
| | I do see interpreter error code -991 from: tests_private__xl__pcl6cet3.0__C101.bin.ppmraw.600.1 (but the job seems to complete) | 22:28.32 |
| | and -954 from: tests_private__xl__pcl6cet__c413.bin.ppmraw.600.1 | 22:30.06 |
| | tests_private__pdf__sumatra__MSVR_201_-_missing_CIDSystemInfo.pdf.pdf.pkmraw.300.0 also looks like a problem. And we have files that don't have any xref (sumatra junk) | 22:33.43 |
| | I really question whether we need to have so many "broken" files in our regression suite that don't produce any data. It obfuscates "real" errors that we may need to look into (such as the MSVR one just above) | 22:34.53 |
| | marcosw (for the logs): do we need a 'scrub' of the test suite to get rid of 'junk' files that don't provide any output, therefore are useless for regression testing ? | 22:36.03 |
| | chrisl_away: (for the logs) I committed a fix for the indeterminism with 09-40.PS that probably should go in the rc. The other commit(s) to get rid of magic numbers are not important, but also low risk. | 23:30.01 |
| | Forward 1 day (to 2015/09/23)>>> | |
IRC Logs