| | <<<Back 1 day (to 2012/06/24) | 2012/06/25 |
| kens | chrisl ping | 07:09.31 |
| chrisl | kens: poing | 07:11.33 |
| kens | chrisl I found out we *do* apply the subfont matrix in pdfwrite | 07:11.52 |
| | gdevpdte.c, line 1125 | 07:12.10 |
| | if (composite) { | 07:12.20 |
| | gs_font *subfont = pte->fstack.items[pte->fstack.depth].font; | 07:12.20 |
| | gs_distance_transform(glyph_origin_shift.x, glyph_origin_shift.y, | 07:12.20 |
| | &subfont->FontMatrix, &glyph_origin_shift); | 07:12.20 |
| | } | 07:12.20 |
| | I believe that the reason meddling with the widths changes the text ,atrix is because when we have a CDevProc I think we always position each glyph individually. | 07:13.09 |
| | Presumably because if we execute a CDevProc, we can't really rely on the widths, tehy could be different every time. | 07:13.35 |
| chrisl | Right, but that's for the origin - where does the subfont matrix get applied for the current point movement? | 07:14.35 |
| kens | Well teh glyph origin is the current point movement in this case, at least I believe it is | 07:15.08 |
| | Still working my way through this | 07:15.21 |
| | If you look a little urther down you'll see a pdf_set_text_state_values | 07:15.56 |
| | That sets the text matrix, which sets the current point | 07:16.06 |
| | (effective current point) | 07:16.13 |
| | Now its entirely possible tha calculation above it is incorrect | 07:16.41 |
| | But the calculation of tx and ty is what sets the currentpoint that gets emitted in the PDF file | 07:17.16 |
| chrisl | But once the glyph is drawn, the current point moves - I'm wonder where the W1x,W1y values are used...... | 07:17.59 |
| kens | I htink shortly below that again | 07:18.25 |
| | After the pdf_char_wisdths_to _uts | 07:18.54 |
| | Its all a bit complex, but I think this is the actual offending area. | 07:19.46 |
| chrisl | Based on what I saw in the rendering case, I don't think the calculation at line 1124 is quote correct, *unless* other stuff is going on elsewhere...... | 07:20.10 |
| kens | The distance transform ? there is other stuff goin gon, its handled in the pdf_glyph_widths stuff | 07:20.57 |
| | But like I say its a bit intertwined, not at all neat | 07:21.10 |
| chrisl | In the rendering case, the matrix applied is parentfont->FontMatrix * subfont->FontMatrix | 07:21.14 |
| kens | All the same I think its process_text_modfy_widths that is the real source of the problem | 07:21.30 |
| chrisl | Yes, it looks like you are correct. | 07:21.44 |
| kens | Its taken quite a while to work through to here :-( | 07:22.03 |
| | THe clue was changing the widths altered teh text matrix.... | 07:22.23 |
| chrisl | I'm not surprised - it's truly appalling that this is *so* different from the "normal" code when it really shouldn't have to be...... | 07:22.48 |
| kens | Yea, its pretty ugly | 07:22.57 |
| | BTW after we applyt the subfont matrix we apply the regular font matrix | 07:23.18 |
| | SO I htink this is effectively the same. | 07:23.42 |
| | Note that we also apply the CTM.... | 07:23.58 |
| chrisl | And then we apply the ctm - hmmmm | 07:24.02 |
| kens | I think I'm going to have to sit down with pencil and paper and work out what the values *ought* to be, then see where they are wrong. | 07:24.51 |
| chrisl | So, does pdfwrite not setup the ctm for glyph "rendering"? | 07:25.00 |
| kens | pdfwrite doesn't set it up , I don't think, no | 07:25.24 |
| chrisl | Again, why so bloody different from the normal case..... | 07:25.42 |
| kens | I have no idea.... | 07:25.54 |
| | ANyway, this was just for your information and 'amusement' really. | 07:26.11 |
| chrisl | where 'amusement' == 'abject horror' ? | 07:26.38 |
| kens | The CTM I see here is definitely not 'normal' [1 0 0 -1 0 6600] so someone has set it up somewhere | 07:26.55 |
| chrisl | I there's a bug in our mailing list server - I just got another "too many bounces" messages, but I received a gs-devel mail this morning...... | 07:29.44 |
| | s/I/I think | 07:29.52 |
| kens | I keep on getting the 'too many bounces' messages | 07:30.04 |
| chrisl | And I was prepared to give the benefit of the doubt on them - but this time, I kind of have evidence to the contrary! | 07:30.48 |
| kens | :-) | 07:30.56 |
| | Oh, and I just got a 'too many bounces' message form gs-devel too | 07:48.05 |
| chrisl | Definitely a bug in there..... | 07:48.19 |
| kens | Something's wrong for sure | 07:48.34 |
| | Oh God, avadhut is back asking stupid questions.... :-( | 09:19.19 |
| | Why do the loons crawl out of teh woodwork on Mondays ? | 09:19.57 |
| sebras | kens: hey! I've been here all weekend! | 09:22.18 |
| chrisl | kens: well, at least it's a fairly easy question... "Explain how pdfwrite works"! | 09:23.44 |
| kens | Yeah, dumb question from dumb user who won't understand the simple answer.... | 09:24.10 |
| chrisl | It seems strange to expect the input file size to be the decisive factor in the output file size - especially when input is PS..... | 09:25.42 |
| kens | They are idiots, enough said :-( | 09:25.53 |
| | Right, stupid question answered. Now, what was I doing ? .... | 09:35.39 |
| Robin_Watts | I think the cluster is testing debug builds of mupdf rather than release ones. | 10:36.13 |
| | I'm tweaking the cluster at the moment | 10:40.15 |
| | (Adding stuff for mujstest) | 10:40.21 |
| | It *shouldn't* affect anything else, but if you see any problems, please tell me! | 10:40.36 |
| paulgardiner | Robin_Watts: just pushed a fix for the latest radio-button bugs to paul/forms, if you have a moment. | 11:00.59 |
| Robin_Watts | paulgardiner: Ta. will look in a mo. | 11:01.14 |
| | Trying to grok cluster perl at the moment... | 11:01.25 |
| paulgardiner | Sure. No hurry | 11:01.37 |
| nlogax | Is the the proper way to check the type of something? 42 type /integertype cvx eq | 11:07.51 |
| chrisl | nlogax: you don't need the cvx | 11:08.25 |
| nlogax | chrisl: Oh, thanks :) | 11:08.54 |
| chrisl | nlogax: other than that, yes it's right ;-) | 11:09.36 |
| nlogax | I thought I made it work before by adding it, must've been more broken than I thought :) | 11:09.53 |
| chrisl | It shouldn't make any difference - an executable integer is still an integer. | 11:12.05 |
| Robin_Watts | chrisl: Surely an executable string ? | 11:12.26 |
| | name, sorry. | 11:12.35 |
| chrisl | Nope, still an integer - if you want it to be a name you'd have to cvn it | 11:12.57 |
| Robin_Watts | 42 type /integertype will leave 2 names on the stack, right ? Whatever the type was, then /integertype ? | 11:13.30 |
| chrisl | Oh, I see what you mean - I was thinking the other way round..... yes | 11:14.11 |
| Robin_Watts | (I ask to try and improve my understanding of PS) | 11:14.15 |
| chrisl | I was thinking he wanted to check for an integer with the execute attribute set | 11:14.43 |
| tor8 | Robin_Watts: have you looked through sebras' patches? | 11:38.16 |
| Robin_Watts | tor8: Not yet. | 11:38.25 |
| sebras | Robin_Watts tor8: none of them are terribly important, but may be worth a look. | 11:38.48 |
| tor8 | Robin_Watts: sebras: just read through them now. they look fine to me. | 11:42.25 |
| Robin_Watts | tor8: so, you'll push them then? | 11:42.41 |
| tor8 | Robin_Watts: yes, soon as I finish test compiling and sane | 11:42.55 |
| Robin_Watts | I pushed some stuff in your absence on friday. | 11:43.01 |
| sebras | tor8: you might want to squash them. | 11:43.23 |
| | IIRC they were quite numerous. | 11:43.37 |
| tor8 | sebras: okay. | 11:44.41 |
| Robin_Watts | paulgardiner: I don't like the comment on your last commit | 11:46.49 |
| tor8 | Robin_Watts: hm, I wonder if we can simplify the lifetime management of the lexbuf now that it's dynamically grown. | 11:47.30 |
| paulgardiner | Robin_Watts: I'm not particularly attached to it. How would you improve it? | 11:49.20 |
| Robin_Watts | For radio buttons, first turn off all the buttons in the group. This case covers both widgets explicitly typed as radio buttons, but also groups of checkboxes that are implicitly radio buttons because they share the same parent (and hence share the same name). | 11:52.08 |
| | I found I needed both the commit message and the comment to understand it. | 11:52.42 |
| | but even so, I can't *quite* see how that comment matches up with the code. | 11:53.16 |
| paulgardiner | Sounds like I'd better update the code comment too. | 11:57.33 |
| | Robin_Watts: Seems to be impossible to determine whether a widget is also a field, but for both cases where it seemed I needed to do so, I just need to locate a point in the hierarchy below which all fields share a common name. | 12:21.54 |
| vtorri_ | tor8: hey$ | 12:27.06 |
| | -$ | 12:27.09 |
| Robin_Watts | paulgardiner: Right. | 12:32.01 |
| | Reading the spec it says that fields and widgets can be rolled together, AIUI. | 12:32.18 |
| | paulgardiner, tor8, sebras: Something that occurred to me over lunch... | 12:32.42 |
| paulgardiner | Yeah, that's the whole problem. I know the object is a widget, but I don't know if it is also a field. | 12:33.06 |
| tor8 | hi vtorri | 12:33.08 |
| Robin_Watts | I was talking to Paul on the phone and he pointed out that we can have a single field that appears on multiple pages; change one copy and they should all change. | 12:33.42 |
| tor8 | Robin_Watts: ohhh.... | 12:34.15 |
| Robin_Watts | That's going to present problems for us with our use of display lists etc. | 12:34.22 |
| | it occurred to me that we could use 'generation numbers' to solve that. | 12:34.54 |
| | We tag every page with a generation number (just an integer), and every displaylist inherits that generation number when it's made. | 12:35.36 |
| | Then when we change something in the file that affects a page, we update that number to the next generation number. | 12:36.10 |
| | That way when we come to use a display list we can check instantly to see if it's out of date or not. | 12:36.32 |
| tor8 | Robin_Watts: I don't see the problem, not when we split out the rendering of annotations into separate pixmap destinations that get composited with the page at the end | 12:37.01 |
| Robin_Watts | tor8: If we do that, sure. | 12:37.20 |
| | well actually... | 12:37.32 |
| tor8 | we'd still need to flag the annotations as dirty | 12:37.44 |
| Robin_Watts | suppose I write a new viewer that supports n up | 12:37.45 |
| | and I keep a display list around for each page that's up. | 12:38.00 |
| | yeah, I need a cheap way to ask if my displaylist (whether it's the full one, or the annotations one) is dirty or not. | 12:38.26 |
| tor8 | I'd imagine you keep separate display lists for the page and the annotations on it | 12:38.29 |
| | but as you said, you still need a dirty check | 12:38.44 |
| | that could go in the fz_annot/widget struct though? | 12:39.03 |
| | which ought to be decoupled from the page if as you say they can be reused on multiple pages | 12:39.32 |
| | of course, if we update the underlying pdf objects and use the generation number as the dirty flag we'll have two different fz_annot structs acting as views for the same pdf object. which may be a perfectly good solution too. | 12:41.06 |
| Robin_Watts | tor8: I was thinking more in terms of having something like int page_generation(fz_page *) | 12:45.03 |
| | tor8: I was thinking more in terms of having something like int fz_page_generation(fz_page *) | 12:45.19 |
| | and int fz_annots_generation(fz_annot *) | 12:45.39 |
| tor8 | ah! you confused me, I thought you wanted to use the pdf_obj generation numbers :) | 12:46.05 |
| Robin_Watts | no, sorry. | 12:46.11 |
| | oh, boy, how do I figure out what OS I'm running on within the cluster code...? | 12:46.58 |
| chrisl | Robin_Watts: variable $^O | 12:48.21 |
| vtorri_ | tor8: now that 1.0 is released, is the API frozen ? | 12:49.08 |
| Robin_Watts | vtorri: Much more so. | 12:49.25 |
| | chrisl: Thanks. | 12:50.42 |
| vtorri_ | Robin_Watts: hte answer should yes or no :) | 12:51.27 |
| | +be | 12:51.41 |
| Robin_Watts | vtorri: Then no. | 12:52.10 |
| vtorri_ | i don't know which versioning you're using, but in our case: | 12:52.29 |
| | major++ == API or ABI break | 12:52.45 |
| | minor++ == API addition | 12:53.02 |
| Robin_Watts | *IF* we do a shared lib build, then we'll have to introduce a shared lib init entry point to allow people to specify an API version. | 12:53.04 |
| vtorri_ | micro++ == bug fixes | 12:53.09 |
| | Robin_Watts: not necessary | 12:53.45 |
| Robin_Watts | That's a reasonable scheme for API numbering, not for version numbering. | 12:53.56 |
| vtorri_ | pkgconfig files, if well written could take care of that | 12:54.07 |
| | version numbering is ? | 12:54.33 |
| Robin_Watts | But we don't provide packages. | 12:54.38 |
| vtorri_ | like libtool versioning ? | 12:54.41 |
| | Robin_Watts: the problem is not that *you* don't provide packages | 12:55.03 |
| chrisl | Robin_Watts: that's a pretty conventional versioning scheme for open source SDKs | 12:55.03 |
| vtorri_ | the problem is that there is no packagers interested in making packages | 12:55.20 |
| Robin_Watts | chrisl: Right, but it doesn't necessarily fit with the way we release things. | 12:55.26 |
| chrisl | Robin_Watts: no, just saying...... | 12:55.53 |
| Robin_Watts | If we did an 'API version', field then we might well follow such a scheme. | 12:56.27 |
| vtorri_ | Robin_Watts: you can change that, and begin with that 1.0 (i would say 1.0.0, actually ;) ) version | 12:56.32 |
| | not 'might', but 'must' | 12:56.45 |
| chrisl | Also, *usually* unix shared libs are much simpler than DLLs - the entry points are *usually* just the same as the static library would be | 12:56.54 |
| vtorri_ | and honestly, mupdf would be more used | 12:56.55 |
| Robin_Watts | but tying the API version to the software version is a restriction we don't need to make, IMHO. | 12:57.15 |
| vtorri_ | chrisl: i'm the windows maintainer of the windows port of several libs | 12:57.22 |
| | no problem with that | 12:57.26 |
| | Robin_Watts: software version is like libtool version ? | 12:57.47 |
| Robin_Watts | vtorri: No, we'll be the judge of what we "must" do, thanks. | 12:57.55 |
| vtorri_ | Robin_Watts: sure | 12:58.03 |
| Robin_Watts | I don't know about libtool. | 12:58.12 |
| vtorri_ | do what you want | 12:58.17 |
| | Robin_Watts: so what is "software version" ? | 12:58.44 |
| chrisl | I always find it odd when people say "We really like mupdf because it's small, fast and lightweight" and then "you have to make it bigger, slower and more bloated and loads more people will use it"...... | 12:59.15 |
| vtorri_ | chrisl: about entry points, in static libs on windows, yes it's tricker, but DLL are good, actually | 12:59.33 |
| Robin_Watts | I'm just saying that there should be a separation between the concepts of "MuPDF API" and "MuPDF version" | 12:59.47 |
| vtorri_ | chrisl: currently, i have to provide mupdf sources with our library | 12:59.59 |
| | chrisl: tarball size : 60MB | 13:00.09 |
| Robin_Watts | Suppose we suddenly decide to make the next version "MuPDF 2012" - the API version might only be 1.1 | 13:00.15 |
| vtorri_ | just because of mupdf not being a shared lib | 13:00.22 |
| Robin_Watts | where the version would be "2012". | 13:00.32 |
| vtorri_ | Robin_Watts: ok | 13:00.41 |
| | i agree | 13:00.50 |
| chrisl | vtorri_: all you need to do is have a static ilb package, then you wouldn't have to include mupdf source with your lib | 13:00.55 |
| vtorri_ | Robin_Watts: it's a bit like libtool versioning | 13:00.58 |
| chrisl | s/ilb/lib | 13:01.03 |
| vtorri_ | chrisl: almost no distro provide a mupdf package, that's the problem | 13:01.19 |
| | that's why i have to provide mupdf source code and statically link against it | 13:01.40 |
| | which also means a lot of work each time i update mupdf | 13:01.56 |
| | because you always change the way mupdf is compiled | 13:02.12 |
| chrisl | vtorri_: and all because they're being stupidly dogmatic about *everything* having to be in a shared library - regardless of whether it makes sense or not...... | 13:02.23 |
| vtorri_ | i just mention a fact | 13:02.46 |
| | mupdf is not packaed | 13:02.58 |
| | +g | 13:03.00 |
| | usually, packagers are not the smartest guys on earth | 13:03.13 |
| | havin a good package manager is rare | 13:03.23 |
| chrisl | For this particular nonsense, I tend to blame the distribution policy setters...... which often involves the maintainers, but involves others, too | 13:04.21 |
| vtorri_ | chrisl: also, iirc, tor8 mentioned that static lib is sufficient for mupdf because there is (was ?) only 1 application that uses it : ghostscript | 13:04.34 |
| chrisl | Ghostscrip doesn't use mupdf..... | 13:04.50 |
| vtorri_ | or ghostview or whatever the app mupdfuses | 13:05.10 |
| chrisl | mupdf uses mupdf....... | 13:05.27 |
| | ghostview uses ghostscript..... | 13:05.39 |
| vtorri_ | mupdf is not used in ghostsomething ? | 13:05.48 |
| Robin_Watts | vtorri: Not currently. | 13:05.57 |
| chrisl | Not currently, no | 13:05.59 |
| vtorri_ | ok | 13:06.02 |
| | i remembered something else, then | 13:06.12 |
| Robin_Watts | (Although at various points in its history MuPDF has been known as "GhostLite") | 13:06.16 |
| vtorri_ | wrongly, it seems | 13:06.18 |
| chrisl | Possibly you were thinking of jbig2dec..... | 13:07.01 |
| vtorri_ | maybe | 13:07.21 |
| | i asked it to make dll build of jbig2dec, btw | 13:07.39 |
| | not to mention that static lib is always possible with jbig2dec | 13:07.59 |
| chrisl | jbig2dec can be built as a Unix shared lib, but currently it doesn't build a DLL, IIRC | 13:08.28 |
| | Windows dll, that is | 13:08.35 |
| vtorri_ | iirc, i provided a patch that builds also dll on windows | 13:08.57 |
| | i should check the code again | 13:09.12 |
| chrisl | it may be waiting to be reviewed (by me - I inherited a lot of that stuff when I joined!) | 13:09.35 |
| Robin_Watts | vtorri_: Was that for cygwin or MSVC ? | 13:09.36 |
| vtorri_ | mingw, but should work for others too | 13:10.04 |
| Robin_Watts | OK, so not "for windows" then :) | 13:10.21 |
| chrisl | vtorri_: I think the point is, tor8 is only likely to reconsider the shared lib policy when there is a good *technical* reason for doing so - and not just because of distro dogma...... | 13:10.55 |
| Robin_Watts | Our commercial target for muPDF is for embedded systems. | 13:11.46 |
| | As such, "no bloat" is king. | 13:11.54 |
| | We don't want to have to carry any extra baggage around; if that means rejigging the API every time we release, so be it. | 13:12.19 |
| vtorri_ | chrisl: not only, but for mupdf being more widely adopted | 13:12.36 |
| Robin_Watts | Now, we'd clearly rather not (and indeed the API changes in 1.0 were designed to be as future proof and as consistent as possible) | 13:12.54 |
| vtorri_ | Robin_Watts: i understand, our libs are also targetting embedded devicces, and they are the best for them | 13:13.07 |
| chrisl | vtorri_: not a good *technical* reason...... | 13:13.08 |
| vtorri_ | Robin_Watts: they are currently chosen for Tizen | 13:13.18 |
| | chrisl: ok :) | 13:13.25 |
| Robin_Watts | but the extra work involved in doing a shared lib build for no good commercial reason is hard to justify. | 13:13.29 |
| vtorri_ | Robin_Watts: because they are faster and have smaller memory footprint than other | 13:13.44 |
| chrisl | vtorri_: I found the jbig2dec patch (Bug 691784) - it's in my queue, as I have some other jbig2dec build things to do, I want to tackle them all at once | 13:13.50 |
| | vtorri_: shared libraries are bigger and slower than static linked code...... | 13:14.33 |
| vtorri_ | slower ? because or dynamic linking ? | 13:15.12 |
| | bigger, maybe a bit | 13:15.26 |
| chrisl | PIC code is inherently slower..... | 13:16.03 |
| | TBH, it makes very little odds on modern hardware, though | 13:16.23 |
| vtorri_ | yes | 13:16.56 |
| chrisl | The thing is, it makes sense with glibc, and various other libraries that are linked into executables that are often loaded into memory all at once, but something like mupdf is rarely going to have many instances in memory at once | 13:17.53 |
| vtorri_ | i agree | 13:18.42 |
| chrisl | vtorri_: I guess I should also disclaim that although I understand tor8's point, I don't necessarily agree with the policy ;-) | 13:19.12 |
| vtorri_ | what anoys me is that i have to provide the source code | 13:20.11 |
| | annoys | 13:20.13 |
| | because otherwise i would have always complains about "mupdf is not packaged in my distro) | 13:20.37 |
| | " | 13:20.42 |
| | so i provide mupdf's source code | 13:20.52 |
| | but each time I update, it's a pain to integrate to my build | 13:21.07 |
| | on the other hand, if it changes, it means mupdf is not dead... | 13:21.52 |
| | which is nice as on embeded, mupdf is much more efficient than poppler | 13:22.23 |
| | *much* more | 13:22.30 |
| Robin_Watts | chrisl: I think I killed the cluster :( | 13:29.34 |
| | I thought the clustermaster job was supposed to be run every minute or so by cron, but I can't see any record of that. | 13:30.09 |
| | am I looking in the wrong place? | 13:30.18 |
| chrisl | Hmm, let me have a look.... | 13:30.44 |
| Robin_Watts | oh, wait... it might have just come back to life. | 13:31.21 |
| chrisl | Robin_Watts: it seems to be run every 15 minutes - does that makes sense? | 13:33.11 |
| Robin_Watts | Quite possibly. | 13:33.22 |
| | Where did you see that? | 13:33.26 |
| chrisl | /var/spool/cron/crontabs/regression | 13:33.46 |
| Robin_Watts | I suspect it runs every 15 minutes in case some fool (i.e. me) has done something to kill it in the meantime. | 13:33.51 |
| chrisl | Robin_Watts: so what did you change that makes you think you broke it? | 13:37.00 |
| Robin_Watts | I introduced a typo,and for a while it was saying "regression terminated due to missing clustermaster.pl" | 13:41.01 |
| | having said that, now nothing seems to be happening :( | 13:41.27 |
| chrisl | I guess you could try running clustermaster.pl manually - see if that jogs it on | 13:42.09 |
| Robin_Watts | no, I'd broken run.pl too. | 13:42.44 |
| | Fixed that now... I think the cluster should time out and carry on in a few minutes. | 13:43.06 |
| | I hope at least. | 13:43.09 |
| paulgardiner | Robin_Watts: there's an updated version of the check-box commit on paul/forms | 13:53.10 |
| Robin_Watts | paulgardiner: Your commit message is missing a word or two? Or maybe it has a word or two too many? | 14:10.21 |
| paulgardiner | Bah. Hang on | 14:10.53 |
| tor8 | Robin_Watts: chrisl: about the shared library/distro thing... if we add a sanity version check in fz_new_context to compare headers versus library version and abort if they mismatch, then I think we could provide a linked library for gcc/elf-based unixes and maybe even a dll for windows. hopefully the distros would stop whining then. but please no autoconf! | 14:10.57 |
| paulgardiner | Robin_Watts: Updated | 14:11.56 |
| tor8 | I still don't think we should distribute binaries as a shared library though. | 14:12.32 |
| chrisl | tor8: I think that would be good - my feeling with this is the same as the shared lib linking under GS: we know the distros *will* do it, so at least let's have *some* control over it...... | 14:14.03 |
| tor8 | yeah. and now that we did the main cleanup pass on the api for the 1.0 release, my worries are slightly less | 14:14.40 |
| vtorri_ | tor8: it's not mupdf devs' work to distribute binaries, it's the package managers of distro. Just distribute source files | 14:14.49 |
| tor8 | chrisl: also, jbig2dec gits and releases, when's a good time to do that for you? | 14:15.04 |
| | vtorri_: we provide binaries for customers | 14:15.27 |
| vtorri_ | ho | 14:15.34 |
| | ok | 14:15.37 |
| chrisl | tor8: I've been hoping to put it off until just before the next GS release - unless you have a more urgent need? | 14:15.53 |
| tor8 | vtorri_: though I think most build from source (or at least I hope they do) | 14:16.02 |
| Robin_Watts | paulgardiner: OK, can't see any obvious problems with that - and the functions make stuff clearer. Thanks. | 14:16.16 |
| tor8 | chrisl: well, I have been considering tackling git submodules for thirdparty libraries in mupdf soon-ish | 14:16.27 |
| Robin_Watts | I can't help thinking that doing things just before a release is a great way to get into trouble... | 14:16.59 |
| tor8 | chrisl: but there's still no real urgency, I'll just test and see if this git subtree thing will work across the ghostpdl.git and jbig2dec.git first | 14:17.15 |
| chrisl | tor8: I can't remember what we decided to do about jbig2decm can you? | 14:17.26 |
| tor8 | chrisl: we should bring the two source trees in sync with regard to which build and configuration files are checked in | 14:17.46 |
| | chrisl: I think that was the main deal, the rest should be solved by crontab pulling commits out of gs and sticking them in the jbig2dec.git | 14:18.13 |
| | I think we decided to do something about the web pages and project pages too, add redirects from sf.net to wherever we can keep them under control | 14:18.57 |
| chrisl | tor8: the ghostpdl/gs/jbig2dec *should* have everything needed in it now - there are, I think, a couple extra files are in there to work with the non-autoconf build(s) in Ghostscript | 14:19.21 |
| tor8 | chrisl: from recollection, ghostpdl/gs/jbig2dec has a checked in configure script where the jbigdec git doesn't | 14:20.19 |
| | and the jbig2dec git has SCons and Jam files | 14:20.32 |
| chrisl | tor8: I was going to drop SCons and Jam..... | 14:21.34 |
| tor8 | chrisl: no objections from me! | 14:21.47 |
| chrisl | tor8: I wanted to keep the configure to save further complications with the GS/GhostPDL builds..... | 14:22.20 |
| tor8 | I believe we ought to have a plain, very simple, makefile to just build a static library but I won't argue it if you think otherwise | 14:22.29 |
| chrisl | No, I agree with that - it's on my todo list, but with no real ugrency........ | 14:23.05 |
| tor8 | chrisl: okay. doesn't gs and ghostpdl require autoconf installed though, to build from source? | 14:23.08 |
| | chrisl: I think the jbig2dec git has a plain unix makefile with just $(CC) etc in it, nothing fancy | 14:23.30 |
| chrisl | tor8: To build from a git checkout, we need autoconf - but I wouldn't want to force people to run extra autogen.sh scripts to the configures all in place....... | 14:24.26 |
| | tor8: actually with the "plain" makefile for jbig2dec, I wanted to ditch all the libtool sh*t - I hate that even more than autoconf :-( | 14:25.05 |
| | tor8: actually, now I look at it, it's probably no big deal to remove the various autoconf generated files from jbig2dec | 14:32.41 |
| Robin_Watts | paulgardiner, tor8: 1 new (tiny) commit on my forms branch. | 14:45.23 |
| paulgardiner | Ok. Will look. Can you push my last one? | 14:45.42 |
| Robin_Watts | I have. | 14:45.59 |
| paulgardiner | ... probably you were thinking to do them together like last time. | 14:46.00 |
| | Oh right. Ta. | 14:46.05 |
| Robin_Watts | but only just :) | 14:46.13 |
| paulgardiner | That commit looks fine, provided MIN is present on all platforms. | 14:49.03 |
| Robin_Watts | well, the rest of pdf_forms uses MIN( :) | 14:49.32 |
| | and it's defined in fitz.h (just checked) | 14:49.46 |
| paulgardiner | Ooops" I thought I specifically looked. | 14:49.57 |
| | Is that me doing while (c = *s++) ??? but, but, I never do that! | 14:50.28 |
| Robin_Watts | No, that was me. | 14:50.48 |
| paulgardiner | Ah! I tend to do for (c = *s++; c; c = *s++) | 14:51.41 |
| Robin_Watts | I dislike the while (c = *s++). But I really dislike the for where you repeat the code twice. | 14:52.24 |
| | I should have done: while ((c == *s++) != 0) from day 1. | 14:52.39 |
| tor8 | Robin_Watts: I know gcc drops the warning if you just add two levels of parens: while ((c = *s++)). not sure if msvc recognizes the same. | 14:54.15 |
| Robin_Watts | I am aware of that (horrible) gccism. | 14:54.34 |
| | Adding parens should not change the semantics of anything. | 14:54.53 |
| | Adding the explicit != 0 seems much nicer to me. | 14:55.06 |
| | MSVC doesn't whinge at all. | 14:55.28 |
| tor8 | avoiding assigning and testing the value in one statement is much nicer too. | 14:55.36 |
| Robin_Watts | tor8: Yes, but the alternative is to repeat code. | 14:56.00 |
| tor8 | while (*s) { ...stuff...; s++; } | 14:56.20 |
| Robin_Watts | while (*s) { c = *s++ ; ... stuff } | 14:56.45 |
| | so you dereference s twice. | 14:56.55 |
| | marcosw: Ping. | 15:33.42 |
| kens | Off for the night, goodnight all | 16:23.52 |
| Robin_Watts | Night kens. | 16:23.57 |
| mvrhel | good morning | 16:24.23 |
| Robin_Watts | Morning. | 16:24.32 |
| | mvrhel: it seems I may have broken the cluster. | 16:24.42 |
| | I'm hoping marcosw will appear soon to berate me. | 16:24.56 |
| mvrhel | oh ok,. thanks for the heads up | 16:25.03 |
| Robin_Watts | If you need to use the cluster before he arrives, I can git reset and hopefully fix it. | 16:25.31 |
| mvrhel | I am hopefully working on my last issue in this copy alpha stuff | 16:25.34 |
| | I will not need the cluster for awhile | 16:25.41 |
| henrys | Robin_Watts:might be worth it to sms him. | 16:27.39 |
| Robin_Watts | henrys: I have. | 16:27.53 |
| henrys | oh okay | 16:27.59 |
| | wow the entire state is burning ... I've never seen things this bad. | 16:28.22 |
| Robin_Watts | and I'm writing him an email explaining what I've done too, as I have to pop out soon to get Helen. | 16:28.41 |
| | henrys: It's all those Utah sharpshooters. | 16:28.58 |
| henrys | well eventually it will use up all the oxygen ... oh wait. | 16:29.17 |
| | chrisl:good to see the device stuff getting straightened out ... | 16:52.35 |
| chrisl | henrys: yeh, getting there - the Epson thing is a pain, though :-( | 16:52.59 |
| henrys | I'd just remove it. | 16:53.13 |
| chrisl | Yep, I probably will - I'd be shocked if it gets used these days..... | 16:53.44 |
| mvrhel | yes. found my dumb copy_alpha bug | 16:55.38 |
| | now I need to do the cluster push..... | 16:56.00 |
| Robin_Watts | Does this mean you want the cluster? | 16:56.02 |
| mvrhel | no word from marcosw yet? | 16:56.10 |
| Robin_Watts | no. | 16:56.14 |
| mvrhel | strange | 16:56.18 |
| Robin_Watts | Let me try stashing my changes. | 16:56.23 |
| mvrhel | Robin_Watts: I have plenty of other stuff to do | 16:56.28 |
| | I can work on another bug | 16:56.35 |
| | don't make extra work for yourself | 16:56.45 |
| | or make matters worse :) | 16:57.01 |
| | I am happy to have found this issue | 16:57.13 |
| | I have no shortage of bugs on my plate | 16:58.35 |
| Robin_Watts | Well, I've backed out my stuff. | 16:58.45 |
| | and it's still saying down :( | 16:59.52 |
| mvrhel | ok. dont worry about it | 17:00.04 |
| nlogax | What could I do that would be equivalent to /foo /ProcSet findresource, except I would provide the path myself, and would not need the Resource/ProcSet/extensionsfreefile structure? | 17:03.13 |
| | Just (...) run it perhaps? :) | 17:03.59 |
| chrisl | nlogax: that might be enough - although it might just load it into VM, then you'd still need to do a findresource | 17:04.44 |
| nlogax | chrisl: Yeah would have to do that, but the path/structure requirements would be gone at least | 17:05.38 |
| chrisl | nlogax: IIRC, defineresource leaves the resource dictionary on the top of the operand stack - "built in" resources pop it off immediately, but you possibly don't need to, as it would avoid the findresource. | 17:09.14 |
| henrys | tor8:I'm wondering if your viewer can be the official viewer with ghostscript and all the languages - assuming we can hook it up with pdfwrite in some sane manner. | 17:10.26 |
| tor8 | henrys: that would be a fair bit more work, but I will think about how it can be done | 17:11.09 |
| nlogax | chrisl: Ah yeah, I pop them away... But would feel dirty to just leave them there :) | 17:11.10 |
| chrisl | nlogax: it depends on how you're using it, but yeh, I know what you mean..... | 17:11.53 |
| Robin_Watts | henrys: That way, we'd end up with a viewer that has all the flaws of all our products :) | 17:20.39 |
| | gotta go pick up helen. bbs. | 17:22.03 |
| mvrhel | oops | 17:22.47 |
| | I had one quick question for you Robin_Watts | 17:22.56 |
| marcosw | hello Robin_Watts, I just saw your text | 17:36.57 |
| mvrhel | oh hey marcosw | 17:54.09 |
| | Is the cluster back up and running? | 17:54.32 |
| marcosw | mvrhel: appears to be, the nodes timed out after 120 minutes and I'm running a test job to make sure. | 17:57.50 |
| | mvrhel: btw, how's the wife? | 17:58.22 |
| mvrhel | she is starting to get around a bit more now | 17:58.34 |
| | thanks for asking | 17:58.36 |
| | marcosw: so I will wait until you give the ok before doing a clusterpush | 17:58.56 |
| | marcosw: where are the irc logs stored? I wanted to grep on something | 18:00.43 |
| Robin_Watts | back. | 18:01.04 |
| marcosw | Robin_Watts: hey | 18:01.12 |
| Robin_Watts | marcosw: Hi | 18:01.14 |
| mvrhel | oh maybe Robin_Watts can refresh my memory | 18:01.15 |
| marcosw | mvrhel: /home/ghostbot/infobot-1.5.3/log | 18:01.38 |
| | on casper | 18:01.43 |
| Robin_Watts | sounds right. | 18:01.49 |
| mvrhel | Robin_Watts: I recall we had some limit on the number of planes we could have due to some hard coded number of line pointers or something of that nature | 18:01.55 |
| Robin_Watts | To search the irclogs, click on the link above (in the topic line), then click current.htm. | 18:02.52 |
| | Then in the top right corner there is a 'search' box, and by the power of google you can find stuff. | 18:03.08 |
| mvrhel | oh | 18:03.14 |
| | nice | 18:03.20 |
| Robin_Watts | Yes, there is such a limit. | 18:03.30 |
| | just a tick. | 18:03.31 |
| mvrhel | how did I not notice this search before... | 18:04.12 |
| marcosw | mvrhel: the cluster appears to be running okay, as long as you don't try clusterpushing a mujstest job :-) | 18:04.29 |
| mvrhel | cool thanks | 18:04.37 |
| Robin_Watts | In gs_get_bits_params_s we are limited to GS_CLIENT_COLOR_MAX_COMPONENTS | 18:04.38 |
| | marcosw: I've backed out all my changes. | 18:04.44 |
| | Can you look them over with a view to putting them back in please? | 18:05.00 |
| mvrhel | Robin_Watts: yes. but I thought there was a limit that this could be | 18:05.08 |
| marcosw | Robin_Watts: thought maybe you had, since build.pl was reporting an error when called with mujstest | 18:05.17 |
| Robin_Watts | mvrhel: Yeah, still looking. | 18:05.19 |
| mvrhel | oh ok | 18:05.25 |
| | 32 pointers | 18:05.50 |
| | gxgetbit.h | 18:05.57 |
| | line 42 | 18:05.59 |
| | the power of the search | 18:06.03 |
| | on irc logs | 18:06.05 |
| | you told me this on march 12th | 18:06.24 |
| Robin_Watts | I was looking exactly there, but I can't see why now. | 18:06.40 |
| marcosw | brb | 18:06.49 |
| Robin_Watts | mvrhel: That's in the middle of a comment for me. | 18:07.37 |
| mvrhel | looks like line 46 now | 18:07.50 |
| | it was line 42 | 18:07.53 |
| Robin_Watts | Right. | 18:07.59 |
| mvrhel | hmm did I change it to GS_CLIENT_COLOR_MAX_COMPONENTS | 18:08.11 |
| Robin_Watts | byte *data[GS_CLIENT_COLOR_MAX_COMPONENTS]; | 18:08.12 |
| | yeah, hence no limit there any more? | 18:08.22 |
| | a limit of 32 sounds like maybe we used a bitmask somewhere to say what components are/aren't included ? | 18:09.17 |
| mvrhel | yes. ok. so this was changed with the tiffsep devn stuff. and it looks like things dont work properly when we set it to something like 64 | 18:10.09 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=693064 | 18:10.23 |
| | likely you are right | 18:10.33 |
| marcosw | Robin_Watts: I'm back and able to look at the mujstest cluster code now, where can I find it? | 18:11.24 |
| Robin_Watts | marcosw: On the mujstest branch. | 18:11.34 |
| | (of the cluster repo) | 18:11.38 |
| mvrhel | Robin_Watts: this may be a good bug for you to figure out.... | 18:12.03 |
| Robin_Watts | Sure. Want to leave it with me? | 18:12.25 |
| mvrhel | ok. that would be a help for me | 18:12.36 |
| | thanks | 18:12.38 |
| Robin_Watts | no worries. | 18:12.43 |
| | My last task at the moment is "get mujstest working", so I now have something else to look at. | 18:13.06 |
| marcosw | Robin_Watts: why are there branches called alexher, chrisl, henrys, ... ? | 18:15.08 |
| Robin_Watts | are there? | 18:17.20 |
| | Oh, that might be the gitbridge stuff. | 18:17.45 |
| marcosw | pwd | 18:18.01 |
| | wrong window :-) | 18:18.05 |
| Robin_Watts | marcosw: Where are you seeing that? | 18:19.40 |
| marcosw | if I execute 'git branch' in ~regression/cluster | 18:20.04 |
| | just to get all my stupid git questions out of the way why does git status report: | 18:20.52 |
| | # Your branch is ahead of 'origin/master' by 2 commits. | 18:20.54 |
| Robin_Watts | because we've committed 2 things to git and not pushed them to the remote. | 18:21.17 |
| | i.e. they live in the git repo in ~regression/cluster, but not the one on git.ghostscript.com yet. | 18:21.45 |
| marcosw | right, so I won't worry about that. | 18:21.59 |
| Robin_Watts | OK, those user named branches are all bogus. | 18:22.45 |
| | And now they are all gone. | 18:23.58 |
| mvrhel | bbiaw | 18:24.16 |
| marcosw | I have to run out for a while, will look at the mujstest stuff when I'm back (assuming the cluster is idle). | 18:28.57 |
| Robin_Watts | Thanks. | 18:37.21 |
| | mvrhel: So the problem (or at least the problem I hit) is down to gs_device_memory_s having a limited number of planes in it. | 19:22.54 |
| | GX_DEVICE_COLOR_MAX_COMPONENTS = ARCH_SIZEOF_GX_COLOR_INDEX * 8 | 19:23.17 |
| | That define made sense when we were packing colors into an index (as we need at least 1 bit per plane), but makes less sense now. | 19:24.13 |
| sebras | Robin_Watts: the form filling code, does that reuest the test to be entered twice!? | 19:31.29 |
| Robin_Watts | sebras: Not as far as I know, why? | 19:31.43 |
| sebras | Robin_Watts: I'm seeing strange phenomena in X11. | 19:32.07 |
| | I know tor8 added fgets-support to make it useful at all. | 19:32.27 |
| Robin_Watts | Nope, just once under windows. | 19:33.01 |
| sebras | whenever I click on a field a prompt appears in the terminal where I started mupdf "> [] ". then I enter "hello" and press enter. then a second prompt appears "> [hello\n] ". the \n in there is meant to be interpreted (hard to show this via irc! :) ). then I have to enter "hello" and press again before the text is actually shown. | 19:34.21 |
| | the text inbetween [] I apparently the inittext from the callback. | 19:34.45 |
| | s/I/is/ | 19:34.59 |
| Robin_Watts | I suspect something is wrong with the logic, so it's responding both to mouse down and mouse up and calling the callback on both. | 19:35.44 |
| sebras | Robin_Watts: seem plausible. | 19:36.12 |
| Robin_Watts | Maybe on windows, because the window pops up, we get different results ? | 19:36.15 |
| | You could look in _onmouse and check that it only calls wintext (or whatever it is) when status = 1 | 19:36.43 |
| | being called for food. | 19:36.53 |
| sebras | np. I'm already looking. I didn't think of both up/down events, but now when you mention it I guess it is fairly obvious. | 19:38.38 |
| | Robin_Watts: yup, you're right. the argument to pdfapp_onmouse(), state, == 1 at first and == -1 the second time. | 19:44.54 |
| mvrhel_laptop | Robin_Watts: ok that makes sense | 20:27.25 |
| | about GX_DEVICE_COLOR_MAX_COMPONENTS | 20:27.36 |
| | darn still 4 files with segvs | 20:30.48 |
| sebras | Robin_Watts: are you there? | 20:42.15 |
| | Robin_Watts: I'm not sure I get this. why are form widgets sensitive to mouse presses? isn't th consensus that widgets should only be responding when a button is released over them? | 21:55.06 |
| | Robin_Watts: and "changed" in pdf_pass_event() is set for both types of events. this is what triggers two calls to wintextinput(). | 21:56.11 |
| | Robin_Watts: also fz_matrix* is passed everywhere in pdf_form.c. in the rest of mupdf fz_matrix is passed directly (no pointer). do you and paul forsee that the form code will be called so often that it's worth the effort? mind you, get_matrix() can likely be made simpler if it by default returns an identity matrix or the found matrix (both with ->e and ->f adjusted of course). | 21:59.33 |
| | doing so would likely help in the next function create_text_appearance() which doesn't have to test for the oldtm argument anymore. | 22:00.09 |
| | or am I missing something subtle here? | 22:00.16 |
| mvrhel_laptop | bbiaw | 22:03.46 |
| Robin_Watts | sebras: I'm here. | 22:34.38 |
| | I think widgets can respond to rollover etc too ? | 22:34.53 |
| | Personally, I feel we *always* ought to be passing pointers rather than values for matrices. | 22:35.38 |
| | marcosw: ping | 23:43.54 |
| | Forward 1 day (to 2012/06/26)>>> | |
IRC Logs