| | <<<Back 1 day (to 2012/03/05) | 2012/03/06 |
| kens | There are days when I despair of Ghostscript: | 09:20.51 |
| | #define nt_log2_sub_size NT_LOG2_SUB_SIZE /* in inameidx.h */ | 09:20.51 |
| chrisl | kens: So, are you going to do the honorable thing, and change the occurrences and remove the stupid macro macro? | 09:37.48 |
| kens | Nope | 09:37.58 |
| | I might break something | 09:38.12 |
| | I'm too busy being baffled by the name table at the moment | 09:38.21 |
| | Right at the moment I don#'t even understand the name hashing | 09:39.00 |
| chrisl | When I looked at it again, I'm not sure the name table was broken in the way I thought it was - even working names seemed to have weird values in "nt->names->names.pvalue" | 09:40.47 |
| kens | What's worrying me is that I come in with the same name and end up with different hashes.... | 09:41.13 |
| | Does that mean the sanem name ends up in the name table multiple times ? | 09:41.35 |
| chrisl | Could the name have been restored away? | 09:41.42 |
| kens | That is a possibility I considered | 09:41.52 |
| | But the colour space is defined once at the beginning of hte file, so I don't think so. | 09:42.12 |
| | The hash function looks like it should give the same hash for teh saem input data, so maybe I'm missing something | 09:43.12 |
| | Of course nt_log2_sub_size is a compile time definition, and I don't actually know what its value is. | 09:44.24 |
| chrisl | If only there was some way to expand a macro....... | 09:44.50 |
| kens | Its not a macro exactly. And I don't know how to do it in ddd | 09:45.08 |
| chrisl | If you build with the gcc options "-gdwarf-2 -g3" you can display #defined values just like constants (and show complete macro definitions with "macro expand" at the gdb command line) | 09:46.36 |
| kens | What do you think the chances are that building with different compile options will make the problem go away ? | 09:46.59 |
| chrisl | I wouldn't like to bet on it! | 09:48.07 |
| kens | I may try it, it will take a while for a complete rebuild on my VM so I'm not hugely keen | 09:48.31 |
| | OK at least hte hash on Windows and Linux is hte same that's somewhat encouraging | 09:49.24 |
| | but phash is different :-( | 09:50.11 |
| | It 'looks' like all this code is doing is finding a slot in the name table, adding the string object to it, and altering the string object into a name object | 09:52.53 |
| | So it messes with the attribute bits and such, but that's really all | 09:53.12 |
| | So maybe I don't really understand what's going on (no surprise) | 09:53.48 |
| chrisl | Yes, but what I don't understand is why the name table has a "strings->strings" part, and a "names->names" part, since the "names" entry doesn't actually seem to contain name objects....... | 09:54.50 |
| kens | That I don't understand at all | 09:55.12 |
| | There are some comments about it in inamedef.h | 09:56.10 |
| | If name.pvalue is 0 then its not defined. If its 1 then its 'other' anything else means its 'valid' | 09:57.24 |
| | If its only defined in systemdict or userdict then its a pointer to the value. No idea what it means otherwise, no how you tell. | 09:57.59 |
| | Apparently this is 'an important optimisation to avoid lookup for operator and other global names' | 09:58.33 |
| chrisl | wtf is "other"? | 09:58.52 |
| kens | Good question. Commetn doesn't say. | 09:59.07 |
| | Maybe it means its defined, but is not only defined in systemdict or userdict | 09:59.24 |
| | ie its not an operator or global name | 09:59.33 |
| | So you need to do a lookup | 09:59.42 |
| chrisl | By process of elimination, that's probably it - very (ahem) clear..... | 10:00.03 |
| kens | So the fact that the string is OK and the pvalue is 1 (I guess) means the name table is intact. | 10:00.31 |
| | I think.... | 10:00.35 |
| | So back to trying to find out why I'm getting an emoty string back | 10:01.01 |
| | empty | 10:01.05 |
| chrisl | Where are you getting the empty string? | 10:01.54 |
| kens | pdf_color_space_named. | 10:02.08 |
| | 4th execution IIRC | 10:02.18 |
| | Err, no, just a mo | 10:02.38 |
| | Right routine, wrong place. | 10:03.07 |
| | At about line 1206 is the Separation case, break on that and the 4th occurence (so ignore count=3) | 10:03.31 |
| chrisl | Yeh, that's where I was looking yesterday when it all started working for me :-( | 10:04.44 |
| kens | :-( | 10:04.52 |
| chrisl | That's using the name index to retrieve a string from the name table | 10:05.20 |
| pabix | Hello, I would like to know whether my submission at bugzilla no 692855 for mupdf ( http://bugs.ghostscript.com/show_bug.cgi?id=692855 ) has been considered for integration. | 10:05.23 |
| | if a developer is around or can suggest improvements to it | 10:05.35 |
| kens | In obj_string_data op0->value->bytes is 0 | 10:05.45 |
| | pabix the developers have undoubtedly seen it. | 10:05.58 |
| | However they are working extremely hard on the 1.0 relelase and may not yet have done anything with it. None of them are online right now though | 10:06.24 |
| sebras | pabix: how come you want to specify the resolution in megapixels? | 10:06.36 |
| pabix | okay. Is there any way I can push to a branch onto the MuPDF git repository? | 10:06.46 |
| sebras | pabix: would options for specifying the width and height be good enough for you? | 10:06.59 |
| | pabix: no, you'll have to maintain your own repository for your own patches. :) | 10:07.14 |
| pabix | sebras: it comes that I'm using MuPDF to generate thumbnails for PDF documents with -r 200 typically, but I have hit a PDF of 25 square meters. | 10:07.45 |
| kens | pabix that doesn't look like an improvement the developers are likely to approve. THough I could be wrong | 10:07.58 |
| pabix | so I added that option in order to downscale the -r parameter if the output image would exceed some dimension measured in pixels | 10:08.17 |
| kens | Of course you can write your own application based on MuPDF and pdfdraw | 10:09.03 |
| pabix | kens: I dislike having to fork a project, but for the moment I'm just maintaining my patch and constantly rebasing it in my own MuPDF repository | 10:11.22 |
| kens | pabix its not my project, I'm merely commenting that I doubt they will take the patch, but I could be wrong. Bear in mind that MuPDF is really the underlying library architecture and the various applications are merely functional demos for the most part. | 10:12.25 |
| | chrisl is there any way I can get ddd to remember my breakpoints *and* their properties ? Resetting them each time is tedious.... | 10:16.48 |
| pabix | kens: thanks. | 10:16.50 |
| chrisl | kens: it should remember everything except the "ignore" value | 10:18.22 |
| sebras | pabix: is it important for you to keep the aspect ratio? otherwise I guess parameters specifying the width and height to be the same for all your thumbnails would be sufficient? | 10:18.29 |
| kens | chrisl that's the one I want it to remember :-) | 10:18.41 |
| chrisl | No, unfortunately, the ignore count is a bit noddy on that front :-( | 10:19.28 |
| kens | That's one way to describe it.... | 10:19.44 |
| | Its bad enough with 2 breakpoints. | 10:19.53 |
| | tor8 can you review the log conversation with pabix please. | 10:21.47 |
| tor8 | kens: it sounds like a -maxwidth -maxheight argument would be a more useful set of arguments than -maxpixelcount | 10:23.57 |
| | pabix: ^ | 10:24.09 |
| | and accomplish the same goal | 10:24.22 |
| kens | has no useful opinion | 10:24.25 |
| tor8 | basically 'fit to width / height / page' depending on which of the arguments are present | 10:24.58 |
| sebras | tor8: or just specifying the desired width/height. | 10:26.14 |
| Robin_Watts | pabix: Yes, tor8 and I discussed your patch when it was first submitted. | 10:26.15 |
| | I'd like to see -s 640,480 or something | 10:27.56 |
| | and then have another flag to control aspect ratio. | 10:28.17 |
| kens | chrisl something definitely zaps the memory in the name table containing the string | 10:28.58 |
| | I see it gets created, and the memory gets overwritten before I get to the pdf retrieval of the colour space name | 10:29.23 |
| Robin_Watts | kens: Use Memento? | 10:29.32 |
| tor8 | how about -w 640 -h 480 and preserve aspect ratio by possibly making a smaller image if it doesn't match | 10:29.36 |
| kens | Robin_Watts : won't go wrong for me on Windows in any build at all | 10:29.53 |
| Robin_Watts | tor8: -h is already used. | 10:29.58 |
| sebras | tor8: that's better then you can say -w 640 -aspect 16:9 if you want to. | 10:30.06 |
| Robin_Watts | kens: So... use memento on linux ? | 10:30.08 |
| | Ignoring the fact that -h is already used, I like the idea of -w blah -h | 10:30.30 |
| tor8 | sebras: aspect ratio in this case would more likely be for non-square pixels | 10:30.37 |
| kens | Robin_Watts : any change to the source tends to make the problem go away, so I'm *highly* reluctant to change anythign at all. chrisl is unable to reproduce now for some reason also. | 10:30.46 |
| sebras | tor8: oh. | 10:30.51 |
| Robin_Watts | because you can use -w 200 (to get a width of 200, and a height of whatever is required) | 10:30.52 |
| | or -h 200 (to do the other way) | 10:31.00 |
| sebras | tor8: when is that used? | 10:31.05 |
| | other than in PAL/NTSC-video systems... | 10:31.16 |
| Robin_Watts | But if you do -w 200 -h 200, you'd probably actually NOT want a 200x200 images. | 10:31.18 |
| tor8 | Robin_Watts: -h is not used...? | 10:31.48 |
| Robin_Watts | You'd probably want 'the largest scale possible so that the page fits within 200x200 without distorting the natural aspect ratio of the page. | 10:31.57 |
| pabix | sebras, Robin_Watts : sorry was away. Yes, for me aspect ratio is important. Limiting the area was a more convenient way for me to setup an upper bound to the output. However -w -h could be used to fix a maximal dimension, and maybe an optional --keep-aspect-ratio | 10:32.05 |
| Robin_Watts | Oh, I thought -h was "help" | 10:32.10 |
| sebras | Robin_Watts: if you set both width and height, haven't you explicitly stated that you don't care about aspect ratio? | 10:32.14 |
| chrisl | kens: do you know if it does a garbage collection between the two points? | 10:32.27 |
| tor8 | Robin_Watts: nah, you get the help on any unrecognised option (which -h is...) | 10:32.32 |
| sebras | Robin_Watts: or that you want whatever aspect ratio you get from -w and -h? | 10:32.33 |
| kens | chrisl no idea, how would I tell ? | 10:32.38 |
| | Might explain the reproduction difficulty though | 10:32.51 |
| sebras | lunches. | 10:33.00 |
| chrisl | Put a break point in the top level gc routine, I suppose | 10:33.02 |
| kens | Do you know the name ? | 10:33.15 |
| Robin_Watts | sebras: Right, but that's not a use case that many people will want. | 10:33.19 |
| chrisl | Not offhand, no...... | 10:33.29 |
| Robin_Watts | I mean, if you're making thumbnails of pages, the odds are you want them to fit nicely. | 10:33.45 |
| | You don't want them so distorted they are unrecognisable. | 10:34.10 |
| chrisl | kens: you could try interp_reclaim() | 10:34.19 |
| kens | chrisl OK I'll set a breakpoint there too. | 10:34.34 |
| pabix | Robin_Watts: I agree with you that distortion is a rare case. | 10:35.03 |
| kens | chrisl any idea how to set a memory watchpoint in ddd ? | 10:36.11 |
| | Can I just type the memory location instead of the function name ? | 10:36.25 |
| | Ah, no, its a different button | 10:36.40 |
| pabix | Still, I feel that when -r is provided, -w and -h should just fix an upper limit, and there should be no upscaling. When -r is not provided then the maximal resolution such that the output fits into the rectangle specified with -w and -h should be used (do you think likewise?) | 10:37.13 |
| chrisl | Don't use the button! IIRC it only gives you local scope for the watchpoint | 10:37.17 |
| | Use the memory address, and the gdb "watch" command | 10:37.44 |
| kens | :-( | 10:38.02 |
| | Seems to have worked though | 10:38.11 |
| Robin_Watts | pabix: If we have to work just with -w/-h then yes. | 10:38.32 |
| kens | chrisl looks like we are doing a vmreclaim | 10:38.42 |
| chrisl | Oh, maybe newer gdb's work correctly, then. | 10:38.46 |
| Robin_Watts | but I'd prefer -w 200 -h 200 --fit or something. | 10:38.53 |
| chrisl | kens: That's a shame, the string memory may have moved legitimately, then | 10:39.15 |
| Robin_Watts | pabix: Now, if you want to give us a patch that does that, we'd be much more inclined to take it :) | 10:39.36 |
| pabix | Robin_Watts: when I've time I will do it then. | 10:39.53 |
| kens | chrisl yes :-( | 10:40.16 |
| | But I think the string table is still referencing the old location. | 10:40.40 |
| pabix | Is there some developer that pushes the official repository of MuPDF to github, so that I can fork his project? | 10:40.55 |
| chrisl | kens: could this be a local vs global VM problem? | 10:41.13 |
| Robin_Watts | pabix: Is MuPDF on github ? | 10:41.13 |
| kens | chrisl at the moment I'm just fumbling in the dark. | 10:41.48 |
| Robin_Watts | pabix: We push to git.ghostscript.com | 10:41.49 |
| kens | The first reclaim hasn't touched the memory | 10:42.00 |
| | Doing another one now. | 10:42.07 |
| | Memory watchpoints are 'rather slow' in the VM | 10:42.23 |
| | I'm guessing no hardware support | 10:42.53 |
| chrisl | Yes, it's likely the VM "CPU" doesn't fully support hardware watchpoints | 10:43.00 |
| kens | So this may take some considerable time | 10:43.20 |
| chrisl | If the string is being added to the name table, I'd be suspicious if it was in local VM - especially when pdfwrite is relying on it | 10:43.45 |
| kens | pdfwrite only relies on it being present while the colour space is valid, it copies it when it sees it being used. | 10:44.09 |
| | So it should not be restored away before we see it or anything. | 10:44.36 |
| chrisl | Well, since I can't see the problem, I'm out of ideas....... | 10:48.02 |
| kens | Yeah, I'll just have to wait :-( | 10:48.12 |
| | At least its (slow) progress | 10:48.27 |
| guilhem | hi! | 10:48.52 |
| chrisl | And I'm back to cust 532 - Type 3 glyph disapears into clist........ | 10:49.02 |
| kens | Yes I saw your reply email | 10:49.12 |
| guilhem | do you know how to activate the auto-reload feature of mupdf? | 10:49.12 |
| | (I'm referring to http://bugs.ghostscript.com/show_bug.cgi?id=691332, that is marked as fixed) | 10:49.32 |
| tor8 | guilhem: hit the 'r' key | 10:49.47 |
| chrisl | kens: as I say, I've got as far a following it into the clist - and there be dragons...... | 10:50.00 |
| kens | chrisl you need ray_laptop.... | 10:50.13 |
| guilhem | I was more thinking of auto-reloading, tor8 | 10:50.29 |
| tor8 | guilhem: or, if you're on a unix-like platform, send mupdf a sighup | 10:50.41 |
| chrisl | kens: I think Ray has his plate rather full already - that's probably why this landed at my door | 10:51.05 |
| guilhem | hmm there is no "watch"-like function, then? | 10:51.15 |
| kens | Oh, I guess you are right chrisl | 10:51.21 |
| tor8 | we're not fond of polling the filesystem, and the filesystem event callbacks are too platform specific for our taste | 10:51.36 |
| | guilhem: no, but it shouldn't be too hard for you to add one if you really want it | 10:51.54 |
| guilhem | right tor8 | 10:52.21 |
| | thanks for the tip with SIGHUP | 10:52.46 |
| chrisl | kens: just a thought - "-Z4" might tell you something...... | 10:52.53 |
| kens | Really ? OK I'll try that too. | 10:53.10 |
| tor8 | the sighup was added for people who do latex previews, you can send the signal in the batch or makefile after the pdf is regenerated | 10:53.27 |
| pabix | Robin_Watts: there could have been a developer that configured a remote on github and regularly pushed to it. | 10:54.07 |
| chrisl | kens: It should tell you *some* of what's going on with gc-ing strings - "-Z5" will give more (too much?) info on the same thing..... | 10:54.14 |
| kens | I'll probably get swamped, but lets see. | 10:54.36 |
| Robin_Watts | pabix: If there is, I don't know if them. | 10:54.45 |
| kens | chrisl so where does -Z4 send its output ? | 10:55.35 |
| chrisl | Er, sterr I assume | 10:57.27 |
| kens | I don't see anything emerge anywhere, shouldn't that go to the terminal window ? | 10:57.46 |
| pabix | thanks all for this chat. | 10:58.10 |
| | have a nice day | 10:58.12 |
| chrisl | You're probably going to want to run this at the command line, not through ddd | 10:58.24 |
| kens | chrisl I did | 10:58.32 |
| | ddd is still running | 10:58.40 |
| chrisl | Oh, I get reams of output | 10:58.58 |
| kens | Sorry, WiFi died horribly | 11:08.01 |
| chrisl | For me -Z4 gives reams of output | 11:08.45 |
| kens | Didn't for me :-( | 11:08.52 |
| | But I had to reboot, so now I have to start all over again, ah well.... | 11:09.05 |
| chrisl | Debug build? | 11:09.11 |
| kens | Yes, run from the debugbin direcotyr | 11:09.24 |
| chrisl | <shrug> | 11:09.49 |
| kens | I'm going to concentrate on the memory watchpoint, *something* is writing to that memory | 11:10.16 |
| Robin_Watts | kens: I reckon that *trying* a memento build has to be worth it. | 11:13.46 |
| kens | Robin_Watts : I did on Windows, no idea hwo to on Linux | 11:14.02 |
| Robin_Watts | make memento ? | 11:14.09 |
| kens | FWIW the Windows build failed in the expected manner until I tried the Memnto build. OK I'll try it. It'll take some time | 11:14.31 |
| Robin_Watts | In memento, all it's global variables are stored in a structure called 'globals'. | 11:16.24 |
| | There is one, globals.sequence that increments over time showing the number of allocation events that have happened. | 11:16.59 |
| | If your code is crashing at the same point every time, then using that should enable you to track down exactly when it happens. | 11:17.24 |
| kens | Robin_Watts : thre is no crash | 11:17.35 |
| Robin_Watts | OK. If it's corrupting at the same point... | 11:17.55 |
| kens | We write a Separation colour space with an empty name | 11:17.56 |
| Robin_Watts | Then you can use Memento_breakAt() to get yourself back to just before it corrupts. | 11:18.21 |
| kens | Robin_Watts : the memory location is different every time | 11:18.33 |
| | Its the same sequence but the actuall address is different | 11:18.45 |
| Robin_Watts | Right. Cos of the helpful address randomisation thing. | 11:19.01 |
| kens | Yep | 11:19.06 |
| | At least I assume that's the case on Linux | 11:19.20 |
| chrisl | Try reloading the executable between each run | 11:20.03 |
| kens | chrisl the effect is the same as far as I can tell, I've done both | 11:20.19 |
| Robin_Watts | kens: http://gcc.gnu.org/wiki/Randomization | 11:20.44 |
| kens | Hmm, that would help if it works | 11:21.07 |
| | I wish Windows would let you do that too | 11:21.20 |
| | OK well the good news is that a Memento build reproduces the problem. | 11:48.51 |
| | Now to work on the memory addresses. | 11:49.03 |
| halabund | Hello everyone | 11:54.25 |
| | I have some PDF figures that I need to convert to EPS before submitting them to the journal (for some reason they always want EPS). When I convert to EPS using xpdf's pdftops -eps tool, I get a huge 10 MB file. The original PDF is only 300 kB. | 11:55.30 |
| | Do you have any hints on what might be going wrong? | 11:55.38 |
| kens | yes, its the dumb device | 11:55.51 |
| halabund | I can upload the file (either the PDF or the EPS) is taking a look at it would help | 11:55.54 |
| | The PDF has a rasterized part, but I do not know in what way it is stored there. I exported it from Mathematica. | 11:56.19 |
| chrisl | Why not ask the xpdf people? | 11:56.28 |
| kens | As chrisl says, that's not a GS product | 11:57.30 |
| | I would guess it rasterises the whole PDF | 11:57.56 |
| halabund | I don't really care about the tool, I just want to get a usable EPS ... can I convert to EPS using GhostScript? | 11:58.10 |
| | to an EPS with a proper bounding box | 11:58.24 |
| kens | Yes, but the result may not be any better | 11:58.28 |
| | epswrite uses the pswrite device at rpesent, and its not very bright | 11:58.41 |
| halabund | I tried the pdf2ps command that comes with MikTeX. I think that uses Ghostscript. It also gave a huge file. | 11:59.23 |
| kens | Plus, if the PDF contains transparency, then rendering is the only solution | 11:59.36 |
| halabund | It doesn't contain transparency as far as I know (not any visible one). | 12:00.13 |
| | It seems pdf2ps has converted every pixel to a polygon, it looks pretty ugly. | 12:00.37 |
| | This is the PDF btw: | 12:00.40 |
| kens | pdf2ps won't do that with recent versions of GS unless the file contains transparency | 12:01.03 |
| halabund | http://ge.tt/2435ZdE/v/0?c (sample PDF) | 12:01.12 |
| | OK, it looks like MikTeX includes GhostScript 9.00 from 2010, let me see what happens with the latest version | 12:02.23 |
| kens | don't use pdf2ps, use the command line | 12:02.48 |
| chrisl | ps2write produces a 2.5 Mb file | 12:04.29 |
| kens | Newer versions of GS will use ps2write when you invoke pdf2ps. | 12:04.56 |
| | epswrite, however, still uses pswrite. | 12:05.10 |
| | Hang on, I've seen this file before, this is the same person asking about conversion rto shadings, right ? | 12:05.25 |
| halabund | Yes, I just tried 9.02 which gave me a 2.5 MB file. | 12:05.48 |
| | kens: This is the rasterized version of that. | 12:06.03 |
| | It's not the same file, just the same figure. | 12:06.20 |
| | (a similar one actually) | 12:06.34 |
| kens | Well its a 500k PDF file, not 300 | 12:07.25 |
| halabund | I uploaded the wrong one. The 300 kb is pretty much the same thing. | 12:09.01 |
| | OK, this is really annoying, I am going to phone the journal about PDF figures | 12:10.16 |
| | They didn't respond to my email when I asked if they accept PDF | 12:10.25 |
| kens | It has shadings in it, ps2write can't handle shasdings (not a level 2 feature) so converts them to images, hence the size increase | 12:10.59 |
| | They will be converted at 720 dpi, you could reduce that which would make them smaller | 12:11.44 |
| chrisl | Does GS do any kind of interpolation when shadings convert to images? | 12:12.05 |
| kens | Umm, don't know. | 12:12.15 |
| | FWIW you can't make an EPS with ps2write anyway, you have to use epswrite, which is based off pswrite, so the result is even larger and less lovely | 12:12.44 |
| chrisl | Just a recent "exploding file size" problem with the PXL output code turned out to be because the image(s) were being interpolated | 12:13.22 |
| kens | BTW the unxompressed PDF file is 10Mb | 12:13.28 |
| | There are 48 shading dictionaries | 12:14.19 |
| chrisl | <sigh> | 12:14.39 |
| kens | A couple of fonts and a 2250x1501 RGB 8bpc image | 12:15.12 |
| | So the image is 10Mb on its own | 12:15.21 |
| | I guess the size increase is mostly down to the shadings being converted to images (when using ps2write) | 12:16.01 |
| | So the only solution would be a ps3write ;-) | 12:16.18 |
| | And we still need to update ps2write to do EPS output. | 12:16.33 |
| | Which ought to be possible, given that it can do DSC now. | 12:16.50 |
| halabund | kens: Isn't the shadings just in the colour bar on the right? | 12:17.31 |
| kens | halabund : n o idea, I'm reading the raw PDF file | 12:17.45 |
| | But 48 shadings will convert to 48 images | 12:17.56 |
| | Oh the image gets ASCII85 encoded so its not binary, that's why the size is so inflated | 12:19.00 |
| | 1.8Mb when not ASCII85 encoded | 12:20.42 |
| LexRiver | Hi, when I'm trying to execute gs from my program i'm getting this error: GPL Ghostscript 9.04 (2011-08-05) Copyright (C) 2011 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Error: /stackunderflow in --run-- Operand stack: --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push | 12:20.54 |
| kens | Try using 9.05 instead of 9.04 | 12:21.17 |
| LexRiver | but the same command works fine from terminal, any ideas? | 12:21.24 |
| kens | Probably some kind of environment variable | 12:21.55 |
| halabund | Oh, there's 9.05? I downloaded from the wrong site and ended up with 9.02, will upgrade now | 12:22.53 |
| kens | halabund : given the conversion of the shadings to images, and the presence of the PostScript prolog, I think this is a reasonable size for your PDF file. | 12:22.59 |
| | halabund : won't make any difference to your results, I'm using 9.05 | 12:23.13 |
| | The best you can get with GS is ~1.8Mb and that's a *PostScript* file, not an EPS. | 12:23.39 |
| | Because the EPS device is dumb, it will produce much bigger output. | 12:23.54 |
| | Robin_Watts : in Linux, my memento build doesn't seem to have debug symbols | 12:36.42 |
| | Is that right ? | 12:36.48 |
| | Hmm, now my debug build doesn't have symbols either, waht's going on.... | 12:38.48 |
| kens | tries a clean rebuild | 12:40.01 |
| Robin_Watts | Morning Paul. | 13:00.09 |
| paulgardiner | Hi Robin | 13:01.15 |
| ManDay | Can I use gs to "convert" (embed) a png or jpeg bitmap into an eps or ps file? | 13:01.20 |
| | If not, what should I do? (I need the bitmap as ps to incorporate it into groff) | 13:01.50 |
| Robin_Watts | ManDay: I vaguely remember something about a "viewlib.ps" in gs/toolbin or somewhere | 13:03.11 |
| chrisl | There's viewjpeg.ps in lib | 13:03.36 |
| Robin_Watts | and viewgif.ps etc too. Yeah, that's it. | 13:04.03 |
| chrisl | So it should be possible to use those with the ps2write device. | 13:04.39 |
| Robin_Watts | That, plus pswrite might do what you want. No, I don't know how to use it. | 13:04.43 |
| Robin_Watts | starts VMware. How long will the updates take today? bet! bet! bet! | 13:08.14 |
| ManDay | How do I use a PS file? | 13:09.33 |
| | Is there a manpage for that? | 13:09.38 |
| sebras | ManDay: http://stackoverflow.com/questions/4283245/using-ghostscript-to-convert-jpeg-to-pdf | 13:12.50 |
| | ManDay: this is hit #2 on google.com if you search for viewjpeg.ps | 13:13.09 |
| chrisl | ManDay: something like: gs -sDEVICE=ps2write -o output.ps /path/to/gs/lib/viewjpeg.ps -c "(/absolute/path/to/jpeg/file) viewJPEG showpage" | 13:15.30 |
| ManDay | Neither -c nor -o are described in the manpage for gs, how come? | 13:16.53 |
| chrisl | The man page probably pre-dates them | 13:18.12 |
| ManDay | Hrm :| | 13:18.55 |
| Robin_Watts | sebras, tor8: Did you look at the split stuff last night? | 13:19.15 |
| sebras | Robin_Watts: yes, we did. there were some additional functions that should be moved, but more importantly tor8 wanted to expose fz_pixmap (which drags fz_storable along with it). | 13:20.04 |
| Robin_Watts | Right. And oh... | 13:20.22 |
| | Not so keen on dragging fz_storable. | 13:20.33 |
| sebras | Robin_Watts: no, but fz_storable is a part of fz_pixmap, so... | 13:20.48 |
| Robin_Watts | fz_pixmap_details(pix, &base, &w, &h, &n); | 13:20.59 |
| chrisl | ManDay: full(ish) documentation here: http://www.ghostscript.com/doc/current/Readme.htm | 13:21.01 |
| Robin_Watts | fz_pixmap_details(pix, &base, &x, &y, &w, &h, &n); | 13:21.21 |
| | then no need to expose fz_pixmap ? | 13:21.30 |
| sebras | Robin_Watts: we were discussing some set of accessor functions, but tor8 was not too keen on the idea. | 13:21.30 |
| Robin_Watts | Publishing storable is bad, IMHO. | 13:21.55 |
| sebras | I think we agree about that all three. :) | 13:22.20 |
| kens | OK so a clean rebuild gets me my debug symbols back in my debug build. However my Memento build has no debug symbols, and so I can't use it. | 13:24.38 |
| Robin_Watts | and I have no idea why :( | 13:25.57 |
| kens | OK back to the glacial watchpoint then. | 13:26.24 |
| chrisl | If I do make memento the gcc command line has the debug flags | 13:26.35 |
| kens | I only report what I see :-) | 13:26.53 |
| Robin_Watts | kens: Does the link command include -g ? | 13:26.53 |
| | make memento XCFLAGS="-g" :) | 13:27.08 |
| kens | Dunno, how would I tell ? (Please don't tell me to rebuild, that will screw my debug build again) | 13:27.11 |
| chrisl | The resulting binary has debug symbols, too | 13:27.29 |
| Robin_Watts | Oh, the unix makefile doesn't show commands by default. geez. | 13:27.34 |
| chrisl | It does, except for the link step | 13:27.55 |
| Robin_Watts | kens: Not being stupid, but you are running from membin, right ? | 13:28.07 |
| kens | Hmm memobj actually | 13:28.26 |
| Robin_Watts | Oh, right, yes. again unix. | 13:28.33 |
| chrisl | No, unix builds end up in the bin directories too, you fixed that! | 13:29.00 |
| kens | D'oh, so I'm running some dumb wrong executable ? | 13:29.18 |
| Robin_Watts | oh, so maybe membin will work? :) | 13:29.18 |
| chrisl | BTW, the link command is in *obj/ldt.tr | 13:29.18 |
| kens | It always used to be there.... | 13:29.28 |
| | Sigh, OK that one has debugging information. | 13:29.58 |
| Robin_Watts | chrisl: The one thing my Goldfish memory consistently remembers is that I have a Goldfish memory. | 13:30.50 |
| chrisl | Robin_Watts: better than all the (mostly) useless crap than I remember - in preference to the occasional useful thing, which I forget....... | 13:32.06 |
| Robin_Watts | Ubuntu just insisted on restarting. It's becoming windows. | 13:33.00 |
| chrisl | Probably kernel update - not much choice, there | 13:33.20 |
| Robin_Watts | kens: http://stackoverflow.com/questions/9560993/how-do-you-disable-aslr-address-space-layout-randomization-on-windows-7-x64 | 13:36.18 |
| kens | Robin_Watts : I'm on Vista | 13:36.30 |
| Robin_Watts | http://msdn.microsoft.com/en-us/library/bb384887.aspx | 13:37.47 |
| | That implies that there is something in the header of an exe you can tweak to make it NOT use dynamic rebasing. | 13:38.21 |
| kens | Hmm could we add that to the debug config on VS ? | 13:38.27 |
| Robin_Watts | Probably not for pre 2010. | 13:39.05 |
| | but... | 13:39.07 |
| kens | Sigh.... | 13:39.17 |
| | I'll see if the Registry entry is the same. | 13:39.26 |
| | Oh I see its a VS2010 setting | 13:39.54 |
| LaoLang_cool | hello, I have a file leads mupdf closed errorly on windows | 13:39.59 |
| Robin_Watts | There is a tool from ms that lets you tweak options in an exe header. | 13:40.15 |
| | I used it to mark an exe so it would only ever run on 1 core. | 13:40.30 |
| LaoLang_cool | The file is at: http://pdn.sciencedirect.com/science?_ob=MiamiImageURL&_cid=272247&_user=3360731&_pii=S1570023211005952&_check=y&_origin=article&_zone=toolbar&_coverDate=15-Nov-2011&view=c&originContentFamily=serial&wchp=dGLzVlB-zSkWz&md5=752cf7653d1b6a18a681035d87f0849f/1-s2.0-S1570023211005952-main.pdf | 13:40.34 |
| kens | Robin_Watts : There is no SYSTEM hive in the Vista registry :-( | 13:40.45 |
| | Ah, its under LOCAL_MACHINE | 13:41.07 |
| | But no MoveImages key | 13:41.47 |
| LaoLang_cool | hello | 13:42.54 |
| kens | LaoLang_cool : I fyou wnat to report a bug please go to Bugzilla at http://bugs.ghostscript.com | 13:43.34 |
| LaoLang_cool | kens: ok, will do it | 13:44.41 |
| sebras | LaoLang_cool: also verify that the link works, because I had problems accessing it. | 13:45.12 |
| kens | Please attach the file to Bugzilla, rather than posting a link there | 13:45.38 |
| sebras | kens: good point. | 13:45.47 |
| LaoLang_cool | sebras: it needs an account to get the file... | 13:45.57 |
| kens | Robin_Watts : after all that, a Memento build doesn't reproduce the problem. | 13:46.13 |
| LaoLang_cool | it's a website to provide scientific papers | 13:46.17 |
| Robin_Watts | LaoLang_cool: Every hoop we have to jump through to reproduce the problem, roughly halves the odds of anyone ever looking at your bug. | 13:46.54 |
| kens | LaoLang_cool : That's another reason to attach the file. We don't want to sign up to get a sample | 13:46.58 |
| Robin_Watts | Your best bet of getting a fix is to give us a simple, clear, concise bug report with everything with need to reproduce it simply. | 13:47.32 |
| LaoLang_cool | kens: Robin_Watts yes, I will attach the file, I haven't report any bug for mupdf, so I didn't know if it can attach file | 13:48.23 |
| | reproducing is so simple, open the file, that's it.. | 13:48.43 |
| norbertj | hello henrys | 13:48.51 |
| Robin_Watts | struggles to get sebras' multithreaded example to build. | 13:48.55 |
| kens | will be out briefly. | 13:48.58 |
| Robin_Watts | norbertj: henrys is probably asleep at the moment. Can anyone else help ? | 13:49.16 |
| sebras | Robin_Watts: ok..? why is it difficult? | 13:49.31 |
| Robin_Watts | No make file :) | 13:49.42 |
| sebras | Robin_Watts: :) | 13:49.50 |
| norbertj | could you look at 692894 (visibility of the testfiles?) The zip should be not downloadable by others. | 13:49.54 |
| kens | I did that for one bug report I think | 13:50.27 |
| norbertj | IRobin_Watts, in Bugzilla, I can not make a testfile private (ie. the button is not present). | 13:50.41 |
| LaoLang_cool | http://bugs.ghostscript.com/post_bug.cgi | 13:50.41 |
| kens | Done that one now too | 13:50.50 |
| LaoLang_cool | Done.. Bug 692902 | 13:50.53 |
| tor8 | Robin_Watts: leaking storable is indeed something we don't want. in a way I think of fz_pixmap as being like fz_matrix and fz_rect, a simple primitive struct; that's my main opposition to accessors for it | 13:51.01 |
| LaoLang_cool | My english is bad, so it's not so clear ... | 13:51.29 |
| Robin_Watts | norbertj: kens beat me to it :) | 13:51.40 |
| norbertj | kens; thanx. I thought there should also be a button so that customers could mark there files as private. But I have never seen it.. | 13:51.48 |
| Robin_Watts | LaoLang_cool: Thanks. | 13:51.53 |
| | norbertj: It's not easy to do that with bugzilla. | 13:52.03 |
| norbertj | Robin_Watts, kens: I'm using Firefox | 13:52.12 |
| Robin_Watts | (if you know how, please tell us!) | 13:52.21 |
| tor8 | Robin_Watts: one thought that I had yesterday, but it was rather late so may be hairbrained, was to keep the fz_storable struct (with both keep/drop and a void*) as a separate allocation (possibly reuse the store's fz_item for the purpose) | 13:52.35 |
| Robin_Watts | It's unrelated to the browser you use. | 13:52.42 |
| | tor8: no, no, no! | 13:53.01 |
| LaoLang_cool | Robin_Watts: thanks? I should thank you... | 13:53.03 |
| Robin_Watts | I suspect that that would open a whole can of worms with locking. | 13:53.30 |
| LaoLang_cool | I can't test it for mupdf on *nix, don't know if it will lead mupdf be closed. | 13:53.37 |
| Robin_Watts | LaoLang_cool: No, we (well, I) work on windows. | 13:53.56 |
| tor8 | Robin_Watts: that's what I suspected... | 13:54.16 |
| LaoLang_cool | Robin_Watts: do you mean the file has no problem with your mupdf? | 13:54.30 |
| Robin_Watts | LaoLang_cool: No. I just mean that the fact that you can only test on one platform will not in itself cause us to ignore the bug. | 13:56.09 |
| LaoLang_cool | Robin_Watts: ok :) | 13:56.34 |
| sebras | LaoLang_cool Robin_Watts: I did a quick test of 692902 using mudraw on HEAD running in linux and I see no crash and valgrind does not complain either. | 14:00.22 |
| tor8 | Robin_Watts: the current split (which has fz_pixmap in the public interface) is on a branch in my private git | 14:01.57 |
| LaoLang_cool | sebras: ok.. | 14:02.18 |
| norbertj | Robin_Watts: when adding an attachment there should be also a button to make it private (at least henrys told me that once upon a time, but I never have seen the button...) | 14:02.42 |
| Robin_Watts | Me either. I suspect bugzilla just doesn't offer that option. | 14:03.59 |
| | The best option is to speak to someone on here - generally, someone will be awake pretty much all the time :) | 14:04.22 |
| norbertj | Robin_Watts: will do that. | 14:05.32 |
| Robin_Watts | sebras: Got it building - and SEGVing. | 14:07.04 |
| tor8 | Robin_Watts: I think we may have a problem with locking and exceptions that we need to double check in a lot of places | 14:07.18 |
| | where we take the lock, then an exception may take us out of the scope and miss the unlock | 14:07.38 |
| Robin_Watts | *Most* locking should be of the form: lock, do somethign that can't throw, unlock. | 14:07.52 |
| | But yes, for some cases, it's a danger. | 14:08.02 |
| | Any suggestions on ways to spot it automatically gratefully received. | 14:08.20 |
| tor8 | I just spotted one in the text device | 14:08.34 |
| Robin_Watts | We can sane, using a memento build and a low memory limit, then such things will cause files to trip over | 14:09.07 |
| tor8 | once we get 1.0 out the door I think it's time to write a script that checks the source for exception and locking usage | 14:09.07 |
| Robin_Watts | Hard to argue against such a tool :) | 14:12.29 |
| | sebras: Have you checked this tool recently? | 14:14.56 |
| | mt-load-in-main-draw-in-threads2.c - when run on pdf_reference17.pdf, it gets to page 459 then dies with a zlib error. | 14:15.31 |
| | I think maybe my pthreads is dying when we ask it to make more than 320 threads :) | 14:19.04 |
| ManDay | I still can't find a complete synopsis of the gs command line tool. chrisl that page you linked has a lot of info but it's mostly prosa | 14:28.44 |
| | Ah nvm | 14:29.29 |
| | I just found it :-| | 14:29.33 |
| | Thanks | 14:29.34 |
| | Is there a viewpng.ps somewhere? | 14:32.38 |
| chrisl | No | 14:32.44 |
| ManDay | Which of the viewcmyk.ps viewgif.ps viewjpeg.ps viewmiff.ps viewpbm.ps viewpcx.ps viewps2a.ps do you suggest should I convert my png over to so that I can losslessly get it into a ps? | 14:34.02 |
| chrisl | You can't do that | 14:34.28 |
| | Have you tried "convert" from imagemagick? | 14:35.32 |
| ManDay | No | 14:51.29 |
| | What do you mean by "You can't do that"? | 14:51.39 |
| | Is it technically not possible to get a lossless representation in a ps file? | 14:52.01 |
| | I can't quite believe that | 14:52.09 |
| kens | What chrisl means is you are tying to do the wrong thing I think. | 14:52.38 |
| | view*.ps reads files in the native bitmap format, it doesn't convert them into PostScript | 14:52.54 |
| ManDay | Yes, it just embeds them, so I understood | 14:53.49 |
| kens | No, it doesn't embed them. | 14:53.59 |
| | PostScript is a programming language, those programs read the file formats directly | 14:54.12 |
| ManDay | So how are pictures in ps files possible then? | 14:54.57 |
| | (bitmaps) | 14:55.03 |
| kens | You can embed images in PostScript, but not in file formats, as raw data. | 14:55.21 |
| ManDay | "Not in file formats"? | 14:55.40 |
| | Oh | 14:55.44 |
| | I see | 14:55.46 |
| kens | Oh good, I thought my explanation wasn't clear. | 14:55.57 |
| ManDay | It's hard to decipher sarcasm on irc | 14:56.16 |
| | ^^ | 14:56.20 |
| kens | Not sarcastic, I thought I wasn't being clear enough, its hard to explain sioimetimes | 14:56.40 |
| ManDay | Ok, so I would have assumed png would be the first format to have a script for. Pity, JPEG is about the ugliest format i can think of | 14:56.59 |
| | But then again, why did chrisl mean I 'm trying the "wrong thing"? | 14:57.26 |
| kens | PNG didn't exist when PS was created | 14:57.41 |
| sebras | Robin_Watts: I never got any of my mt-examples to work reliably at all. | 14:57.42 |
| chrisl | ManDay: if you convert your png to ppm, then use viewpbm.ps | 14:57.55 |
| ManDay | chrisl: Great, that's teh answer I needed! | 14:58.06 |
| sebras | Robin_Watts: and when I did get them to work I used an 18 page file (boids3.pdf attached in the original mail). | 14:58.23 |
| ManDay | Mind if I ask you why you answered "You can't do that" at first, chrisl ? | 14:58.30 |
| chrisl | Because you asked how to embed your png image in a PS file - you can't do that | 14:58.45 |
| ManDay | Actually, I just said "get it into ps" | 14:59.05 |
| | Which you could have generously interpreted as anything that works. | 14:59.23 |
| | But ok ;P | 14:59.39 |
| chrisl | Well, you also said "png or jpeg" and I gave an answer for jpeg....... | 15:00.48 |
| ManDay | If I wasn't afraid that the humor got lost over IRC I'd like to have replied "F*** you" :D | 15:13.36 |
| | Well, now, thank you chrisl ;) | 15:13.44 |
| chrisl | ManDay: terminology can be a problem in cases like this...... | 15:15.34 |
| Robin_Watts | sebras: Right. | 15:22.20 |
| | I've tweaked the mt-load-in-main-draw-in-threads to keep a list of what threads are active at any given time. | 15:22.49 |
| | And when it gets to thread 371 (on the latest run, varies a bit), further threads are forked, but none of them even get as far as the first print. | 15:23.25 |
| | All the previous threads reach the end though. | 15:23.37 |
| | so they aren't stopping as a result of any locks in my stuff. | 15:23.57 |
| chrisl | Robin_Watts: it may be hitting a resource limit | 15:25.11 |
| Robin_Watts | yeah, I'm thinking that maybe this example is working now. | 15:25.31 |
| | So I might try to hack something else based on it. | 15:25.43 |
| chrisl | Is this Windows or Linux? I'd guess stack memory is being exhausted...... | 15:27.01 |
| Robin_Watts | linux. | 15:27.11 |
| chrisl | What's ulimit say? | 15:28.41 |
| Robin_Watts | unlimited | 15:28.59 |
| chrisl | I think there's a global limit, too. Can't remember how to check it, though. | 15:29.22 |
| | Robin_Watts: I take it these are not concurrent threads? | 15:41.17 |
| Robin_Watts | They are concurrent threads. | 15:48.38 |
| chrisl | Well, nearly 400 threads has got to be hitting some kind of system limit - are the completed threads being correctly "joined"? | 15:49.57 |
| Robin_Watts | No. sebras joins them all at the end. | 15:50.12 |
| | so I'm sure it's a system exhaustion thing - hence me not being fussed about it. | 15:50.28 |
| | I'm trying to do something simpler now. | 15:50.36 |
| chrisl | On linux, threads are processes, so the maximum number of processes is also the maximum *total* number of threads | 15:51.54 |
| paulgardiner | tor8: I've improved search in the android app. The updated version is in ~paulg/repos/mupdf.git on casper if you'd like to take a look sometime. | 15:59.58 |
| | tor8: With highlighting of links, is the intention to put another button next to the outline and search buttons? | 16:01.02 |
| tor8 | paulgardiner: great, I'll take a look at that soon(-ish... buried in some other stuff a.t.m.) | 16:05.19 |
| | yeah, my thought was a toggle button for highlighting links next to the outline and search buttons | 16:05.45 |
| paulgardiner | tor8: no hurry. | 16:05.58 |
| tor8 | paulgardiner: your user repo is visible here http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=summary (and any other git repos you put in ~/repos) | 16:06.58 |
| paulgardiner | Oh ok, thanks. Handy to know. | 16:07.59 |
| Robin_Watts | Bah. I'm running linux in VMWare Player, which is limited to 1core, I believe. | 16:19.14 |
| | so that may affect how hard it is to actually trigger problems. | 16:19.31 |
| | Maybe I need to write my test code on windows. | 16:19.39 |
| chrisl | Try virtualbox | 16:19.52 |
| Robin_Watts | chrisl: No :) | 16:20.05 |
| chrisl | Why? | 16:20.12 |
| Robin_Watts | I'd like to get results sometime this year. | 16:20.23 |
| | Nothing (particular) against virtualbox, but it would be energy going into something at a tangent from fixing the bug. | 16:21.08 |
| | Making it fail under windows would be nicer for debugging too. | 16:21.21 |
| | and it's "just" a matter of using windows threads rather than pthreads. How hard can it be? (TM) | 16:21.44 |
| chrisl | Well, if you're threading interface is well designed - easy peasy..... :-) | 16:22.15 |
| Robin_Watts | MuPDF is completely thread lib agnostic. | 16:22.42 |
| chrisl | I was going to say, vbox can just run your vmware VM, but it will have installed a single CPU kernel, so there would be a bit of fannying about to sort that out. | 16:22.49 |
| Robin_Watts | D'Oh. If you believe your threading problems are to do with image handling, try testing with a file with images in it. | 16:27.38 |
| kens | :-) | 16:29.21 |
| mvrhel_laptop | good morning | 16:34.34 |
| Robin_Watts | Morning Michael. | 16:38.23 |
| kens | Hi mvrhel_laptop | 16:38.42 |
| mvrhel_laptop | Robin_Watts: so I think part of the solution for the tiff sep device to handling more than 8 unencoded colors is going to have it use planar buffers | 16:39.23 |
| Robin_Watts | OK. | 16:39.51 |
| mvrhel_laptop | I may have some questions for you at some point on this | 16:40.04 |
| chrisl | mvrhel_laptop: won't that foul up the composite preview? | 16:40.05 |
| Robin_Watts | mvrhel_laptop: You're working on a branch, right? :) | 16:40.22 |
| mvrhel_laptop | chrisl: why? | 16:40.32 |
| | that is constructed as a CMYK object after the fact with all the proper overprint ect | 16:40.56 |
| chrisl | I just wondered..... | 16:42.01 |
| Robin_Watts | mvrhel_laptop: Is it? | 16:42.14 |
| marcosw_ | mvrhel_laptop: just the guy I needed. do you have an eta on <http://bugs.ghostscript.com/show_bug.cgi?id=692618>? The customer is asking. | 16:42.17 |
| Robin_Watts | I thought the device worked by using the different components as: C,M,Y,K,separation 1, separation 2, etc... | 16:42.41 |
| mvrhel_laptop | yes | 16:42.59 |
| | but the composite preview cant be that | 16:43.05 |
| | psdscmyk is different though | 16:43.18 |
| | it packs it all in | 16:43.27 |
| | marcosw_: this is the bug we are talking about right this second | 16:43.52 |
| | it is going to take a least a month | 16:44.02 |
| chrisl | I vaguely thought that creating the composite preview relied on the color values being in one "block"...... | 16:44.08 |
| marcosw_ | urgh, that doesn't seem like a simple fix. | 16:44.33 |
| mvrhel_laptop | if I have a buffer of all the planes of data, I surely can take that and create the separations and the composite preview | 16:44.44 |
| | I have all the information I need | 16:44.49 |
| | as long as I know how to "convert" the spots to equivalent preview CMYK values | 16:45.12 |
| Robin_Watts | Is this to raise the maximum number of components? | 16:45.37 |
| mvrhel_laptop | marcosw_: no it is not going to be that simple | 16:45.43 |
| Robin_Watts | Otherwise I can't see why planar helps. | 16:45.46 |
| mvrhel_laptop | it is | 16:45.49 |
| Robin_Watts | Right. | 16:45.58 |
| mvrhel_laptop | we have to get the deviceN values in and out of the clist and also goto planar buffers | 16:46.12 |
| chrisl | That's not how it works in the device now, and I'm not sure how easily the tint transforms are available for the spot inks post-process | 16:46.26 |
| Robin_Watts | So you're trying to avoid the encode/decode color step ? | 16:46.36 |
| mvrhel_laptop | there will be no compressed color encoding | 16:46.49 |
| Robin_Watts | That's not what I asked :) | 16:47.04 |
| mvrhel_laptop | what is it that you asked. the device could still do and encode/decode of its color values | 16:47.55 |
| | s/and/an/ | 16:48.07 |
| marcosw_ | Is it possible to work around the problem, using the trick described in <doc/Devices.htm#TIFF>? | 16:48.40 |
| Robin_Watts | encode_color takes an 'n' entry array, and packs it down to a 64bit int, right ? | 16:48.54 |
| | The problem, AIUI, is that when 'n' gets bigger than 8, we can't fit the quart into the pint pot. | 16:49.39 |
| ray_laptop | Robin_Watts: that's what compressed encoding _tries_ to do, yes | 16:49.44 |
| mvrhel_laptop | ah yes. we will not be doing that | 16:49.57 |
| | this is where we have to do some clist work | 16:50.14 |
| chrisl | marcosw_: trick? | 16:50.25 |
| Robin_Watts | ray_laptop: Compressed color encoding is the mechanism by which we try to get the quart into the pint pot. | 16:50.27 |
| | The NEED for having some sort of mechanism is the fact that encode_color/decode_color get called. | 16:50.48 |
| mvrhel_laptop | marcosw_: you mean a multi-pass approach | 16:50.49 |
| ray_laptop | Robin_Watts: correct, but it is failing on some of the files from Gemma | 16:50.50 |
| marcosw_ | using imagemagick to combine multiple composites. | 16:51.00 |
| Robin_Watts | ray_laptop: Yes, I know. | 16:51.00 |
| | The fact is that any mechanism we pick is going to fail in some cases. | 16:51.18 |
| ray_laptop | mvrhel_laptop and I discussed the multipass approach as a 'quick and dirty' approach yesterday | 16:51.20 |
| Robin_Watts | So the only solution is to avoid calling encode_color and decode_color. | 16:51.32 |
| ray_laptop | Robin_Watts: not if we fill using the HL color | 16:51.40 |
| mvrhel_laptop | yes | 16:51.48 |
| marcosw_ | mvrhel_laptop: was the 'yes' in response to my question? | 16:52.17 |
| Robin_Watts | Hence, I deliberately wasn't asking if michael was tweaking/rewriting compressed color encoding. I asked if he was attempting to avoid having encode/decode_color called. | 16:52.21 |
| mvrhel_laptop | to ray_laptop | 16:52.25 |
| marcosw_ | darn. | 16:52.29 |
| ray_laptop | by using the fill_rectangle_hl_color at the device level, we avoid the need to boil down to a gx_color_index | 16:52.41 |
| | Robin_Watts: yes -- the key is to avoid encoding the color | 16:53.03 |
| Robin_Watts | ray_laptop: Right. So, by passing the high level colour through, you are avoiding encode/decode_color. Right. | 16:53.10 |
| | And that's what I was asking. Cool. That sounds ideal. | 16:53.34 |
| | I fear it means yet more hackery in the already hairy devices, but... | 16:53.51 |
| mvrhel_laptop | not really. I believe this approach is better than any alternatives of trying to pack into mem64 chunky with encode/decode | 16:54.40 |
| ray_laptop | Robin_Watts: mvrhel_laptop and I discussed a new buffer device that uses planar buffers (as many as needed for the spot colors + CMYK) as the 'buffer_device' for the devicen capable devices (tiffsep, psdcmyk, ...) | 16:55.17 |
| mvrhel_laptop | plus we can probably to the put_image from the pdf14 device right into the tiffsep planar buffers like we did for the rgbtag device | 16:55.33 |
| | s/to/do/ | 16:55.41 |
| ray_laptop | mvrhel_laptop: correct | 16:55.49 |
| marcosw_ | just to introduce another confounding topic into this discussion how impossible would it be to have tiffsep write out a compressed composite file? Obviously it won't solve all of the issues with the 4 gig size limit, but the for the MPRM file from Gemma a 72 dpi composite compresses 11 to 1 using lzw. | 16:55.52 |
| Robin_Watts | marcosw_: The problem there is we can't know up front that the image will be too big. | 16:56.37 |
| marcosw_ | Robin_Watts: so we always compress it. | 16:56.52 |
| ray_laptop | mvrhel_laptop: there will be substantial changes to the pdf14 device that supports spot color as well (to use HL colors rather than encoded colors) | 16:56.57 |
| mvrhel_laptop | ah | 16:57.05 |
| | yes | 16:57.06 |
| marcosw_ | law has pretty good worst case behaviour | 16:57.07 |
| Robin_Watts | So we might get all the way through rendering, and go to write it out, and find it still won't fit. | 16:57.10 |
| | marcosw_: No, we can definitely tell if we need to try to compress it or not up front. | 16:57.33 |
| | what we can't tell is whether the compression will be good enough. | 16:57.41 |
| ray_laptop | when we compress, we use strips, so we will get some idea of the compression as we go along (if we query the file size periodically) | 16:59.00 |
| marcosw_ | Robin_Watts: but presumably this is no different than if we write out a tifflzw file. I.e. for some files we fail because we cross the 4 gig limit. And we presumably don't know that ahead of time either. | 16:59.47 |
| ray_laptop | but right now, compression is a user defined option -- we'd have to warn users if we use compression | 16:59.51 |
| Robin_Watts | marcosw_: It might be possible to change the outright fail that we give now to be "Sorry, but we've had to use compression". | 17:00.28 |
| ray_laptop | marcosw: so if you specify compression on the command line (and disable the test in gdevtsep.c) does it work OK ? | 17:00.28 |
| henrys | marcosw_:I think there were several changes in gdevtsep.c that needed to be changed search for max_long. | 17:00.43 |
| | s/changes/places | 17:00.58 |
| | I guess we should start the meeting. | 17:01.12 |
| marcosw_ | ray_laptop: I hadn't tried that, I presumed that tiffsep wrote out an uncompressed composite for a technical reason. | 17:01.13 |
| mvrhel_laptop | there is alexcher | 17:01.50 |
| ray_laptop | marcosw: we form the composite line by line from within memory -- we never read back from the tiff files | 17:01.58 |
| | marcosw: but you will have to remove the test that is causing the rangecheck in order to try -sCompression=lzw | 17:02.37 |
| chrisl | I *thought* the tiff offsets were "raw", so compression won't help - but maybe I'm wrong...... | 17:03.46 |
| henrys | what exactly is the tiff requirement? | 17:03.56 |
| | what chrisl said. | 17:04.02 |
| | mvrhel_laptop and alexcher: are we proceeding with render intent okay? | 17:04.38 |
| alexcher | chrisl: tiff offsets are offsets to the tables in the file. | 17:04.42 |
| ray_laptop | chrisl: tiff offsets are not raw -- they are relative pointers to the strip data | 17:04.45 |
| marcosw_ | chrisl: the checks in the gdevtsep.c file look at ftell(), so they are checking for file size (of course they could be wrong). | 17:04.59 |
| mvrhel_laptop | alexcher: did you get my email with the patch and the test case for you to look at? | 17:05.01 |
| chrisl | Fair enough - I stand corrected. | 17:05.15 |
| marcosw_ | I do find it odd that tiffsep write out lzw compressed separations but an uncompressed composite. | 17:05.54 |
| alexcher | mvrhel_laptop: yes, I've received it but was not able to look into it over the week-end. | 17:06.08 |
| henrys | the fact remains the job can't be printed in acrobat with lzw, adobe says reduce it and so do we. What's the problem. | 17:06.34 |
| | ? | 17:06.35 |
| mvrhel_laptop | alexcher: ok. if you can look at it this week I would appreciate it. I want to wrap this thing up. | 17:07.13 |
| henrys | alexcher:the jpeg2000 bug which you fixed in openjpeg doesn't help the customer is the change for luratech much different? | 17:07.27 |
| | my comment before last was to marcosw_ | 17:08.14 |
| alexcher | henrys: I know this, I'm working on Luratech version. | 17:08.21 |
| marcosw_ | henrys: we want to be better than adobe. | 17:08.35 |
| ray_laptop | marcosw: if the composite is uncompressed when specifying -sCompression=lzw then that is wrong (a bug). | 17:08.45 |
| Robin_Watts | I think the problem may be that we throw the error without even trying to compress. marcosw is right that that is a bug. | 17:09.35 |
| marcosw_ | ray_laptop: aren't individual separations being lzw compressed without specifying -sCompression=lzw equally wrong? | 17:09.44 |
| henrys | marcosw_:fine raise a P4 bug but the customer should be told this is the acrobat behavior and it exactly matches ours as far as the user is concerned, that is our obligation to them. | 17:12.16 |
| mvrhel_laptop | alexcher: will you be able to look at the output intent stuff this week? I have a feeling the bug in the interpreter should be easy for you to find | 17:14.23 |
| Robin_Watts | Woo Hoo! I can reproduce the customer bug in my tests on linux. | 17:14.28 |
| henrys | the other meeting discussion item I had was tor8's branch to move the mupdf parser to gs. And since alexcher doesn't have a project after output intent I thought .... | 17:14.41 |
| alexcher | mvrhel_laptop: Of course. | 17:14.42 |
| mvrhel_laptop | ok thanks | 17:14.45 |
| | now that's a project | 17:15.18 |
| Robin_Watts | According to the list of things we each had to do after the meeting, alexcher does have a project. | 17:15.37 |
| | (unless he's finished already?) | 17:15.52 |
| kens | Speaking of projects.... | 17:16.14 |
| | henrys should the prioirty of PDF/A-2 production be ? | 17:16.29 |
| alexcher | Robin_Watts: I need to finish jpeg2000 bug. | 17:16.34 |
| Robin_Watts | alexcher: Oh, is that the last one? | 17:16.57 |
| kens | Its probably a couple of weeks work, but if I leave ti utnil after the PDF server stuff it will be a long time before it is done. | 17:16.57 |
| Robin_Watts | alexcher: kudos if so. | 17:17.16 |
| henrys | alexcher:this does fall directly to your ownership in fact it will replace a lot of what you have so it makes sense for you to work on it. I'm not saying you would complete the whole project soon but you should have a hand in it. | 17:17.22 |
| | I would put PDF/A-2 above pdf server at this point. | 17:17.55 |
| kens | Great, that parllels my thinking too | 17:18.07 |
| alexcher | henrys: yes, replacing PS kludges would be great. | 17:18.08 |
| | henrys: keeping working around 16-bit restrictions is quite silly. | 17:19.27 |
| henrys | ray_laptop, Robin_Watts:what about saying we need to have problems reproduced on their simulator? This would be a bit less than saying ghostscript reproduction, and it seems reasonable. Thoughts? | 17:19.48 |
| | alexcher:well maybe you can start looking at tor8's branch as time permits. | 17:20.16 |
| alexcher | henrys: OK | 17:20.32 |
| ray_laptop | henrys: I can't think of a problem that they've given me that could not be reproduced on the simulator (except for performance) | 17:20.48 |
| Robin_Watts | henrys: That certainly seems reasonable to me. Whether they consider it so... | 17:20.51 |
| | I've only been involved in performance ones though. | 17:21.24 |
| ray_laptop | henrys: BTW, I was successful in making a gswin32c.exe + gsdll32.dll from their sources that just leaves out their device and some of their code (just the "standard" devices) | 17:21.49 |
| henrys | ray_laptop:I was referring to the performance problem recently reported, I didn't understand why that wasn't immediately pushed back on. | 17:21.50 |
| ray_laptop | henrys: because they asked for us to find out why it is so slow | 17:22.46 |
| henrys | part of this is getting them to do more work even if we know we could probably make some progress, nothing is going to change until they dig into the code ... if we do everything they won't do that. | 17:23.37 |
| ray_laptop | but I do find it frustrating that the simulator does the 243 page job in 204 seconds on my laptop and it takes 1400 seconds on their target | 17:23.58 |
| Robin_Watts | I understand henrys point there. | 17:24.12 |
| marcosw_ | ray_laptop: tiffsep does ignore -sCompression=lzw, but according to the documentation that's a feature: "For the tiffsep device, it only changes the compression scheme of the separation files (which is lzw by default), not the composite cmyk file." | 17:24.21 |
| Robin_Watts | 1) How are we ever supposed to find out if we don't have access to their target. | 17:24.29 |
| ray_laptop | henrys: I am becoming convinced that the problem is _not_ in our code, but in something else on the target causing delays | 17:24.37 |
| henrys | ray_laptop:just tell them reproduce it on the simulator and we are happy to work on it. | 17:24.38 |
| Robin_Watts | 2) The bug is clearly in their integration - so it should be them that finds it. | 17:24.54 |
| chrisl | marcosw_: you can make a bug and assign that to me - I need to rejig tiffsep a fair amount in the next couple of weeks anyway | 17:25.10 |
| marcosw_ | chrisl: will do, thanks. | 17:25.27 |
| chrisl | I'm not looking forward to it :-( | 17:25.40 |
| ray_laptop | chrisl: what will you be doing to tiffsep (beyond the compression "fix") ? | 17:25.51 |
| henrys | that's all I had for the meeting anybody else? | 17:25.53 |
| chrisl | ray_laptop: I need to rejig how it manages the files so it doesn't close and reopen them when we get a put_params that requires the device to be reopened. | 17:26.48 |
| ray_laptop | chrisl: I ask because the change to use a planar device that provides separation will change things | 17:26.50 |
| | chrisl: oh -- the "missing first page" problem ? | 17:27.08 |
| chrisl | Yep | 17:27.13 |
| ray_laptop | chrisl: OK. so that is in a separate (no pun intended) than the area mvrhel_laptop will be changing | 17:28.01 |
| henrys | ray_laptop:it really does need to be pushed back - it is a perfect time to set the precedent so we avoid further confusion about where the boundaries of responsibility are. | 17:28.03 |
| chrisl | ray_laptop: sorting it for the separation files is fairly straightforward, but the composite preview is what requires the rejigging | 17:28.40 |
| henrys | I'm happy to do it or I'll ask miles to do it. Let me know. | 17:28.50 |
| ray_laptop | henrys: OK, I've got some instrumentation changes I want them to add, but I'll make sure they know that "since the simulator doesn't show the performance problem, it is something else on their target" | 17:29.43 |
| henrys | thanks | 17:30.01 |
| chrisl | ray_laptop: did you see the type 3 font problem from cust 532 that came in this morning? | 17:30.41 |
| ray_laptop | henrys: I suspect that they may have a hideously slow file system. | 17:30.47 |
| henrys | Robin_Watts, tor8, paulgardiner: I sent mail to raph and copied you guys in, feel free to chime in. | 17:31.33 |
| ray_laptop | chrisl: no, not yet. I just started work when I came online here (taking kids to school). My mornings are full from 6:30am until 8:40 or so :-( | 17:31.39 |
| henrys | meeting adjourned. | 17:32.47 |
| chrisl | ray_laptop: the reason I ask is that it works on "normal" gs, I tracked down where we diverge, and I have a possible fix - but it might be good if you could cast an eye over it? | 17:32.59 |
| ray_laptop | chrisl: thanks for copying support on your reply. We need to remind him to cc support on all traffic to us (he apparently only sent it to you) | 17:33.37 |
| chrisl | I'll send him a quiet, informal reminder | 17:34.36 |
| ray_laptop | chrisl: you can just remind him in your reply if he does it again -- it isn't that critical, but I usually say "by incliuding support@artifex.com it insures that your problem will be seen even if I am on holiday" | 17:36.16 |
| chrisl | Sure, that's the line I was going to take | 17:36.49 |
| henrys | ray_laptop's favorite customer is back 692906 | 17:38.36 |
| chrisl | Yes, "can you quickly explain the Ghostscript code base for me?" ;-) | 17:39.13 |
| kens | Yeah I saw that.... | 17:39.14 |
| | I don't know what that request to support is about, the 'Permission Request' | 17:41.08 |
| Robin_Watts | It's a link-exchange spam. | 17:43.00 |
| kens | Ah, thought it might be something like that. | 17:43.12 |
| henrys | bbiaf | 17:43.37 |
| ray_laptop | when the heck did a Rudyard Kipling quote get added to the website? It makes NO sense !!! | 17:43.42 |
| kens | It includes the 'Artifex' reference. Its been there for some time. | 17:44.10 |
| | OK, I'm off, goodnight all. | 17:44.32 |
| ray_laptop | some english major turned web designer waxed (overly) creative | 17:44.33 |
| | bye, kens | 17:44.40 |
| mvrhel_laptop | whats going on with Artifex website | 17:48.27 |
| | seems to be majorly screwed up | 17:48.41 |
| Robin_Watts | mvrhel_laptop: How so? | 17:48.49 |
| mvrhel_laptop | well.... | 17:48.58 |
| | oh there it goes | 17:49.22 |
| | it was not properly loading for some reason | 17:49.30 |
| | must have been some web hiccup | 17:49.37 |
| | it was only partially loading | 17:50.13 |
| ray_laptop | is our meeting over ? | 17:50.51 |
| mvrhel_laptop | about 20 minutes ago.... | 17:51.03 |
| henrys | yes | 17:51.11 |
| | the kipling quote has always been there, that's where "Artifex" comes from. | 17:52.07 |
| Guest28315 | Hi.. I am facing a problem while converting a PDF to PS using Ghostscript v8.15.2. Is this the right forum to ask question related to this conversion problem? | 17:54.44 |
| ray_laptop | Guest28315: probably the answer will be to try 9.05 | 17:55.37 |
| | Guest28315: 8.15 is ANCIENT | 17:55.56 |
| Guest28315 | true... but its working fine when i convert the same in Windows but not from Linux | 17:56.39 |
| ray_laptop | Guest28315: see http://www.ghostscript.com/download/gsdnld.html | 17:57.00 |
| | Guest28315: 8.15.2 is not a release from Artifex -- some linux distros put in their own modifications/patches and add the extra revision digit. You would have to get support from them | 17:58.36 |
| Guest28315 | Thanks Ray... I have initiated an approval for the latest version download/install, let me see what's the response... | 17:59.13 |
| ray_laptop | Guest28315: our release versions are only a major and two-digit minor | 17:59.21 |
| Guest28315 | But as you pointed i was not able to find out 8.15.2 | 17:59.35 |
| ray_laptop | Guest28315: just curious -- what linux distro are you using ? | 18:00.07 |
| Guest28315 | Linux dvc7712 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux | 18:01.39 |
| ray_laptop | have to go find power -- bbiaw | 18:01.43 |
| | Guest28315: it could be a 64-bit specific issue. Please try 9.05 and let us know if it is still a bug (bugs.ghostscript.com) | 18:02.38 |
| | Guest28315: we occassionally have had things that work OK on 32-bit but don't on 64-bit (more than the other way around). | 18:03.22 |
| Guest28315 | Sure Ray! I will try the same and will get back to you... | 18:04.08 |
| | thanks much for your help | 18:04.18 |
| ray_laptop | Guest28315: and I don't think 8.15 on Windows was 64-bit since until more recently 64-bit was stroingly discouraged because it ran slower. | 18:04.30 |
| | bye,all | 18:04.46 |
| Robin_Watts | Might have found it... | 19:27.44 |
| mclarke_ | I have just downloaded and installed the windows build gs905w32.exe, but it doesn't appear to have the new inkcov device? | 20:01.48 |
| | does anyone know of a windows build that has the new inkcov device? | 20:05.18 |
| Robin_Watts | That's not a default device. | 20:05.32 |
| | You'd have to build it for yourself. | 20:05.38 |
| mclarke_ | ok, thanks, i just assumed it was as it is in the documentation | 20:07.00 |
| Robin_Watts | Let me check if it's a default linux device. | 20:07.24 |
| | It does appear to be in Makefile.in | 20:09.59 |
| mclarke_ | Thanks Robin, (I executed gs -h but inkcov was not in the list of devices) | 20:12.31 |
| Robin_Watts | chrisl: Should inkcov be a default windows build device? | 20:12.48 |
| | mclarke_: chrisl is probably away for the night, but I'll ask him tomorrow and add it if required. but we won't be doing any more release builds until august. | 20:13.29 |
| | but building for yourself is dead easy. | 20:13.52 |
| mclarke_ | OK, thanks, I appreciate your help. I will look into building it myself. | 20:14.27 |
| Robin_Watts | Yell on here if you get stuck. | 20:16.28 |
| chrisl | Robin_Watts: yes, I'm actually off for teh night.... but yes, inkcov should be in the Windows build (disclaimer: I didn't pull it in, in the first place.....) | 20:28.52 |
| Robin_Watts | tor8, sebras: I've updated the split patch with some fixes I spotted when I had to build it on linux. | 20:38.01 |
| | Also, I've added pixmap accessor functions for tor8 to disapprove of. | 20:38.17 |
| | Stops winapp.c needing to use mupdf-internal.c | 20:38.42 |
| malc_ | Robin_Watts: dae93920d513842f6c9a96e833043f3f6f8e0681 introduced memory corruption, can provide a backtrace if needed (FWIW it doesn't trigger with mupdf itself) | 21:32.30 |
| Robin_Watts | malc_: Damn. | 21:32.53 |
| | Please. | 21:32.55 |
| | Oh. | 21:33.47 |
| | In res_store.c | 21:33.53 |
| | at line 273 | 21:34.12 |
| | val->refs++; | 21:34.18 |
| | make that if (val->refs > 0) val->refs++; | 21:34.26 |
| | I bet that's it. | 21:34.37 |
| malc_ | that's line 277 here.. | 21:35.03 |
| Robin_Watts | yes, here too. My reading of the patch was off, sorry. | 21:35.18 |
| malc_ | yep.. it's gone now | 21:35.33 |
| Robin_Watts | Thanks. | 21:36.45 |
| malc_ | anytime | 21:37.27 |
| henrys | mvrhel_laptop:I must be not understanding something - I am setting -sDefaultRGBProfile=../../gs/iccprofiles/ps_rgb.icc I see it picking that file for a profile with -ZC but I'm not seeing fast color management like I'd expect. | 23:46.27 |
| | I thought with ps_rgb.icc I'd get an identity transform with an rgb device. | 23:51.53 |
| | Robin_Watts:692906 is customer 130 probably need a retraction there. | 23:58.19 |
| | Forward 1 day (to 2012/03/07)>>> | |
IRC Logs