| | <<<Back 1 day (to 2015/01/07) | 20150108 |
| rayjj | henrys: there's code in plmain.c that 'blame' has your name for following: /* NB this needs a better solution */ where it sets the pti->high_level_device. Does this need to include xpswrite ? | 04:21.16 |
| henrys | rayjj: I think it's for high level patterns so probably wouldn't effect xpswrite yet. Obviously we should have a parameter that asks for that - not if it is just some device string. | 04:30.42 |
| rayjj | henrys: right -- it's probably better done with a dev_specop | 04:31.14 |
| henrys | off for some tv time see you tomorrow | 04:31.53 |
| rayjj | yuck. pl_main_process_options TOTALLY ignores NULL returns from arg_copy (arg_heap_copy) | 05:24.48 |
| | If I start MEMENTO_SQUEEZEAT at 400, I get past all arg allocations and I'm actually able to start the xps processing. All the way up to sequence 1136 :-) | 06:18.30 |
| | fixes in 7 files so far. Many of these would affect ANY parser (plmain and gsicc issues) | 06:19.52 |
| | time to call it a night. | 06:20.17 |
| marcosw1 | I've managed to bork bugs.ghostscript.com (again), so I'm switching to the hot spare. It will take a while for dns to sort itself out. | 06:36.13 |
| Robin_Watts | tor8: 2 commits on mupdf robin/master. The JPEG resolution one, and one to remove a dead structure. | 11:28.54 |
| tor8 | Robin_Watts: dead struct LGTM | 11:33.50 |
| | Robin_Watts: image res should be fixed for mucbz as well | 11:34.00 |
| Robin_Watts | ok. | 11:34.17 |
| tor8 | Robin_Watts: zenikos fixes also look reasonable | 11:34.51 |
| Robin_Watts | ah, cool. I haven't looked at them. | 11:35.08 |
| tor8 | Robin_Watts: don't take my mujs patch yet, I have some more work on mujs that should be included shortly | 11:46.58 |
| henry___ | Is anyone know how to add a circle/rectangle annotation ? | 13:40.03 |
| henrys | welcome back chrisl happy new year | 14:15.53 |
| chrisl | henrys: thanks, happy new year to you, too | 14:16.16 |
| henrys | rayjj for the logs we agreed some time ago we would not check every single return call. Why are we undertaking this task now? | 14:30.07 |
| | Robin_Watts: feel free to ask fred to use irc for his project questions, I'd prefer it but whatever is best for you and paul. | 14:37.43 |
| Robin_Watts | henrys: We did? | 14:41.36 |
| | Sounds like the kind of decision I'd have railed against. | 14:41.59 |
| henrys | I guess that is not about fred | 14:44.10 |
| Robin_Watts | henrys: About checking every return value :) | 14:45.43 |
| henrys | yes we felt every third line would have been if code < 0 return ... do you really check things like printf etc? anyway we can resurrect that argument next meeting if you like | 14:45.45 |
| Robin_Watts | henrys: Nah, not printf, but you've got to check for errors like memory failures etc. | 14:46.39 |
| henrys | I'm off to chicago today and tomorrow not sure if anyone pays attention to the joanne vacation notice emails | 14:47.10 |
| Robin_Watts | Either you live with the fact that every 3rd line is "if (error < 0) ..." or you adopt an exception handling system like mupdf does. | 14:47.20 |
| | I like to think it's obvious which is better :) | 14:47.45 |
| chrisl | Hmm, I prefer explicit error handling..... I hate stuff being hidden | 14:48.33 |
| tor8 | Robin_Watts: handling errors at the source and not propagating them all the way? ;) | 14:48.54 |
| | I'm still in two minds about the whole exception thing | 14:49.07 |
| Robin_Watts | tor8: How do you handle malloc failures at the source? | 14:49.18 |
| tor8 | Robin_Watts: by ABORTING! :D | 14:49.30 |
| | printf errors should be checked for output devices | 14:49.52 |
| | or at least check the ferror status at the end of a bunch of printfs | 14:50.19 |
| | or we could silently generate crap/truncated files | 14:50.29 |
| rayjj | morning, all | 15:31.47 |
| | henrys: I wasn't going to bother to re-write the plmain startup issues, but IMHO once a parser starts processing, not handling OOM properly should be detected to prevent SEGV | 15:33.12 |
| | and I'm not spending a lot of time on it -- just when I get frustrated with cut 532's performance issues late at night | 15:34.29 |
| | the most frustrating thing about Len's performance problem (871 vs 906) I suspect is not our problem. | 15:35.34 |
| henrys | rayjj: yesterday's regression though really makes me feel review is needed for these types of changes. That bad change could have easily shipped. It passed all the linux machines I have no idea how. | 15:35.34 |
| rayjj | henrys: right. I'll go ahead and get review on the changes. I still don't know how a bare "return" from a function that returns a pointer didn't cause a compiler warning, but it may have and just the "new warnings" detection is broken | 15:37.46 |
| | or maybe gcc was smart enough to do what I meant to (return item) ;-) | 15:38.34 |
| graphicore | Hi, anyone there? | 15:51.54 |
| Robin_Watts | graphicore: Yes. | 15:52.18 |
| graphicore | ah, cool | 15:52.25 |
| | I filed a bug a while ago | 15:52.35 |
| | its still unconfirmed | 15:52.45 |
| Robin_Watts | In general on irc, if you have a question, ask it, and hang around, don't ask to ask it :) | 15:52.46 |
| | What bug number? | 15:52.52 |
| graphicore | ok! | 15:53.02 |
| | Can anyone confirm http://bugs.ghostscript.com/show_bug.cgi?id=694982 | 15:53.11 |
| | It blocks a project of mine. | 15:53.29 |
| Robin_Watts | That would be a question for mvrhel, I think. | 15:55.27 |
| | What version of gs are you using? | 15:55.42 |
| graphicore | I just compiled from master | 15:56.08 |
| Robin_Watts | Ok, so git head. | 15:56.24 |
| graphicore | yes | 15:56.28 |
| Robin_Watts | I'd be tempted to try using gs -o out.png -sDEVICE=png16m tritone.pdf | 15:57.01 |
| | and comparing the output pngs. | 15:57.14 |
| | Just in case it's a specific problem with the display device. | 15:57.21 |
| | But that's just a wild guess. | 15:57.30 |
| graphicore | gives the same results | 15:59.34 |
| Robin_Watts | ok, so you need to wait for mvrhel to have a spare moment to look at it. | 15:59.57 |
| rayjj | The display device is a DeviceN aware device, but the way it *mashes* the planes together to get the display view is just an approximation. | 16:00.08 |
| graphicore | basically yes | 16:00.21 |
| rayjj | you can examine the planes directly to make sure they are correct and that the profile is being applied | 16:00.54 |
| Robin_Watts | rayjj: So use -sDEVICE=tiffsep then? | 16:01.20 |
| rayjj | AFAIK, mvrhel never looked at the algorithm that Russell uses to get the RGB from the planes | 16:01.46 |
| graphicore | I don't think the profile is applied, at least one of two examples in the bug should show differences. | 16:02.37 |
| rayjj | Robin_Watts: yes, the tiffsep or the psdcmyk device (the latter will let you view with Adobe's algorithm for DeviceN->RGB on the screen) | 16:02.38 |
| graphicore | Also, about the approximation, isnt there a way to give a display profile as well? then it should be all color managed I suppose | 16:03.11 |
| rayjj | *if* I were to looke at it, I would check the psdcmyk device | 16:03.21 |
| Robin_Watts | Can we use pam? If so, you can view the planes using: http://ghostscript.com/~robin/pamview.html | 16:03.49 |
| graphicore | I have an old photoshop cs2 running on wine (on linux). The results still don't differ there with -sDEVICE=psdcmyk | 16:16.10 |
| chrisl | So, by my reading of the docs, the -sDeviceNProfile option supplies a *source* profile for DeviceN input, not an output profile for DeviceN output...... | 17:14.34 |
| rayjj | graphicore: you posted the EPS, but not the "artifex_tritone.icc" your example needs | 17:32.48 |
| graphicore | the icc profile is in the git repository | 17:33.33 |
| chrisl | toolbin/color/icc_creator/example/artifex_tritone.icc | 17:33.49 |
| graphicore | it's possible that I use it wrongly in the eps file, but the pdf file belongs to the profile | 17:34.35 |
| rayjj | chrisl: Oh, I was looking in iccprofiles. graphicore did you move artifex_tritone.icc to the iccprofiles directory ? | 17:35.11 |
| graphicore | no, I just symlinked it into my testdirectory | 17:37.06 |
| | chrisl: yes, right, so I thought. The output should use -sOutputICCProfile I think | 17:41.33 |
| chrisl | graphicore: Yes, with a suitably tailored profile | 17:42.13 |
| graphicore | chrisl: But shouldn't the output still differ when the source profile is different, even if it uses a default conversion for the output? | 17:45.16 |
| Robin_Watts | unless the profile is the default one? | 17:46.56 |
| chrisl | graphicore: I really don't know enough about the area to say - hence my quoting the docs.... for example, in your example, the fact the DeviceN space is inside an indexed space might cause problems.... | 17:47.04 |
| graphicore | chrisl: yeah, that's part of my problem, that I don't know enough either. If I had a working example I could find my way using that. From my understanding, the DeviceN in the EPS is used correctly. All examples in the PLRM that use DeviceN put it into an indexed space. | 17:58.35 |
| rayjj | graphicore: Note to see the separations on the display device you need -dDisplayFormat=16#a0800 | 18:22.38 |
| | Also, the tint transform for Artifex Orange is messed up -- is that intentional ? 1.0 0.5 0.0 0.0 (Artifex Orange) should be: 0.0 0.5 1.0 0.0 (Artifex Orange) to make an actual orange | 18:24.24 |
| | Note the tint transform is what the display device uses to create the separation color and to "mash" separations to RGB -- it NEVER uses ICC profiles | 18:25.47 |
| graphicore | rayjj: yes, it is intentional, to see the cm working. " it NEVER uses ICC profiles" so the display device it is not colormanaged? | 18:33.10 |
| | Forward 1 day (to 2015/01/09)>>> | |
IRC Logs