| | <<<Back 1 day (to 2017/04/05) | 20170406 |
| amila | good morning | 06:40.34 |
| | HI | 08:45.19 |
| 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. | 08:45.19 |
| Robin_Watts | Morning amila. | 08:49.29 |
| amila | good morning robin | 08:53.34 |
| | hi | 11:55.32 |
| 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. | 11:55.32 |
| Robin_Watts | Morning amila: You'll frequently wait a long time waiting for people to reply to greetings on irc. Your best bet is just to ask any questions you may have, and we'll answer as soon as we can. | 12:01.54 |
| amila | in what kind of operating sistem is better to develop with ghostscript? | 12:10.03 |
| | i normaly use windows but i like to use ubuntu | 12:10.53 |
| kens | Whichever operating system you like best and feel most comfortable with | 12:17.43 |
| | Amongst the developers we use a mix, someo | 12:18.02 |
| | sorry, hit enter in error | 12:18.09 |
| | Some primarily use WIndows, some Linux, and we sometimes use MacOS | 12:18.33 |
| ray_laptop | amila: I would chime in that if your target RIP product will be linux based, and you are comfortable with ubuntu (or another linux), then doing your initial development there might be better. The only difference is the top level makefiles are different between Windows and linux/MacOS | 13:11.24 |
| | and the "display" device on the two platforms differ (x11 vs Windows) | 13:12.08 |
| | many of us use both fairly equally, I tend to use Windows as the native OS and use VS 2015 mostly there, but am equally comfortable on linux and prefer profile and other tools on linux (gprof, valgrind, ...) | 13:14.02 |
| amila | i normaly use ubuntu to program but on windows i start to use vs 2017 | 13:40.11 |
| kens | The solution provided to build Ghostscript on WIndows should work with VS 2017, but will need to be updated. Visual Studio should offer to do so when you first open the solution | 13:41.15 |
| amila | the rip is for windows and mac because in italy many companies use windows and mac there are few companies use linux | 13:42.25 |
| ray_laptop | amila: I see, so the RIP product is software provided to customers to use on their own computers (you don't provide a "bundled" product with the software pre-installed on hardware), is that correct? | 14:00.55 |
| | amila: can you tell us what input data formats you will want to accept (PS, PDF, PCL, XPS, ....) | 14:02.36 |
| | amila: and, I should mention that if you are not able to provide answers in public (here), but can privately, please feel free to email us and we will keep it private | 14:03.52 |
| amila | what is your email | 14:20.51 |
| ray_laptop | amila: support at artifex.com | 14:26.07 |
| | amila: all of the engineers see that (kens, robin, myself included) | 14:26.40 |
| amila | ok | 14:36.50 |
| kens | chrisl the problem in bug #6797548 is from param parsing in setpagedevice for me | 14:39.33 |
| | <</Margins[]>> setpagedevice cauzses the seg fault | 14:39.45 |
| ray_laptop | mvrhel_laptop: I thought you were out this week | 14:39.53 |
| chrisl | kens: Yeh, I see it, I was just being a bit stroppy, tbh | 14:40.00 |
| kens | :-D | 14:40.08 |
| | Seems to me that param_read_float_array should be able to cope with empty arrays | 14:40.41 |
| chrisl | I don't think that's the problem | 14:41.21 |
| kens | You may be correct | 14:41.28 |
| | I only just poked at it just now | 14:41.36 |
| chrisl | I think it's more about having a dictionary object as a key | 14:41.57 |
| kens | I'd forgotten that we unrolled all this stuff onto the stack | 14:42.00 |
| chrisl | Hmm, okay, no. It doesn't like a dictionary as a value..... | 14:50.54 |
| kens | well setpagedevice shouldn't normally be using a dictionary as a key | 14:53.00 |
| | So I'd be inclined to throw it out with an error.... | 14:53.22 |
| chrisl | I was wrong, it doesn't like the dictionary as a value for /Margins | 14:53.51 |
| kens | Yeah that's more what I thought | 14:54.00 |
| | Margins is looking for a float array | 14:54.07 |
| | SO a dictionary ought to trigger a typecheck error | 14:54.17 |
| | I htionk its because the array is empty though. Note that the dictionary is not properly balanced, tehre are not an even number of entries (key + value) | 14:54.59 |
| chrisl | Yes, it is balanced | 14:55.23 |
| kens | Really ? I must have missed something then | 14:55.39 |
| chrisl | findfont is an operator | 14:55.45 |
| kens | True, but it will return what ? | 14:56.08 |
| chrisl | Well, for me, it is trying to find a font with a name of an empty array | 14:56.47 |
| kens | If it returns anythign it will be a single dictioanry | 14:57.19 |
| chrisl | Yes. | 14:57.27 |
| kens | Which measn we have <</Margins [] <dict> /[]>> | 14:57.59 |
| chrisl | No, findfont takes a parameter | 14:58.12 |
| | <</Margins <dict> /[]>> | 14:58.26 |
| kens | Ah, so you think its swallowing the array ? | 14:58.28 |
| | Shouldn't that throw an error ? | 14:58.34 |
| | Hmm, apparently not | 14:58.57 |
| | it seems we are allowed to use a key for findfont | 14:59.16 |
| chrisl | Yeh - ick :-( | 14:59.39 |
| kens | well the float array shuld throw an error when the object on the stack is not a float array then, surely. | 15:00.13 |
| | I'm assuming that findfont returns the default substitute font when presented with [] as a key | 15:00.42 |
| chrisl | Yes | 15:00.48 |
| | The problem is that ref_param_read_typed() doesn't *enforce* a type | 15:01.14 |
| kens | Hmm, I htought there was something that did | 15:01.25 |
| | But I haven't looked at this stuff in a while | 15:01.44 |
| chrisl | param_coerce_typed() ? | 15:01.52 |
| kens | Sounds plausible | 15:02.02 |
| | Though I have a suspicion that *forces* the parameter into a type, rather than ensuring it is a type | 15:02.21 |
| chrisl | That's the only place in that code path I can see that will return a typecheck | 15:03.49 |
| kens | I guess its that then | 15:03.59 |
| chrisl | param_coerce_typed() will "coerce" sort of compatible types - and integer into a float, or an integer array into a float array - but not a dictionary into an array etc | 15:05.47 |
| | But that gets called *after* we've hit the problem :-( | 15:06.08 |
| kens | Yet more evidence of the crapness of our setpagedevice implementation | 15:06.44 |
| | I think we need to rework that bit, if we expect an array, and don't get one, then it should be an error | 15:07.20 |
| chrisl | Well, I'm a bit baffled why we're trying to do stuff with the object, before we've validated it | 15:08.14 |
| kens | THat does seem silly | 15:08.34 |
| chrisl | Okay, we're trying to enumerate a dictionary, with stack_param_enumerate() | 15:10.45 |
| kens | Hmm, well that isn't going to work | 15:11.09 |
| chrisl | I'm looking at line 775 in psi/iparam.c | 15:12.12 |
| kens | give me a minute, I'd dropped it and gone back to PDF | 15:12.32 |
| chrisl | Oh, well, leave it then, I'll carry on | 15:12.44 |
| kens | Right I see, its enumerating a dictionary | 15:13.06 |
| chrisl | In the conditional, we call the function pointer plist->enumerate | 15:13.39 |
| kens | yes I see | 15:13.45 |
| chrisl | *But* we pass in pvalue->value.d.list | 15:13.56 |
| | So, plist, at this point, is the param list for the operand stack, but pvalue->value.d.list is the param list for the dictionary | 15:14.42 |
| kens | That seems screwy | 15:15.10 |
| chrisl | I feel it is not the intended usage.... | 15:15.43 |
| kens | I guess it works as long as the value is a dictionary, and not some other compound type | 15:16.12 |
| chrisl | If I change that so it uses the enumerator for the dictionary param list, it no longer crashes | 15:19.57 |
| kens | Well, that sounds positive.... | 15:20.12 |
| | But I wonder what other implications there are | 15:20.23 |
| chrisl | I'm going to have a play with this, and see. At the moment, I'm not getting the error I expect, but that could also be down asan stomping all over the output | 15:21.14 |
| kens | Hmm, OK | 15:21.31 |
| | I'll go back to PDF then | 15:21.37 |
| chrisl | No, even a debug build doesn't throw an error.... weird | 15:22.32 |
| | Oh, I think setpagedevice ignores the erroneous value - which seems right...... | 15:24.46 |
| kens | ignoring the nonsense seems like the right thing to do | 15:38.16 |
| | IIRC its perfectly legitimate to stick asnything you like in the dictionary to setpagedevice, and it just ignores anything it doesn't understand | 15:38.40 |
| chrisl | Yes, "invalid values for the current device are ignored" - or words to that effect. I looked it up a minute ago | 15:40.47 |
| kens | OK so I finally sorted out the colour space stuff, which fixed exactly one file :-( | 15:45.52 |
| | On ot the next problem I guess | 15:46.03 |
| chrisl | kens: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=bfa6b2ecb | 15:48.31 |
| kens | That looks rather more sensible | 15:49.15 |
| chrisl | cluster shows no changes | 15:49.36 |
| kens | I assume nothing blows up if yo udo that ? | 15:49.36 |
| | :-) | 15:49.40 |
| | I'd say go for it then | 15:49.49 |
| chrisl | Cool, thanks | 15:49.57 |
| | kens: I've also got: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=47417a5cb | 15:50.36 |
| kens | Ah yeah, I'd fogotten about that | 15:50.55 |
| | Again, looks very sensible | 15:51.05 |
| | It'll be nice to access big memory on 64-bit Windows builds | 15:51.17 |
| chrisl | Right,. pushed - thanks | 15:52.04 |
| kens | Great, two nice fixes | 15:52.10 |
| | Forward 1 day (to 2017/04/07)>>> | |
Log of #ghostscript at irc.freenode.net.