| <<<Back 1 day (to 2013/05/23) | 2013/05/24 |
vtorri | Robin_Watts: ping | 06:18.35 |
| tor8, hey | 07:23.04 |
| tor8, i have implemented the display of outline of a pdf | 07:23.35 |
| tor8, it wors well on the pdf i have, except 1 thing | 07:24.05 |
| the pdf is : | 07:24.10 |
| http://www.tug.org/applications/hyperref/ftp/doc/manual.pdf | 07:24.27 |
| so the TOC is at the first page | 07:25.51 |
| and subsections 4.1.1 and 4.1.2 should be in | 07:26.07 |
| but i can't have them when iterating over the outline | 07:26.26 |
| tor8, can you check that with your programs, mupdf gets them (so it would be a problem on my side) | 07:27.07 |
| ? | 07:27.09 |
tor8 | vtorri; mudraw -l | 07:27.30 |
| (lowercase L as in outLine) | 07:27.40 |
vtorri | is there a wndows binary of mudraw somewhere ? | 07:27.57 |
tor8 | the outline does not have a 4.1.1 or 4.1.2 section. | 07:28.23 |
vtorri | ok | 07:28.50 |
| so not a problem on my side | 07:28.58 |
tor8 | I thought you were on linux? | 07:29.06 |
| the regular mupdf windows download has the mudraw binary in it. | 07:29.21 |
vtorri | it would have been strange as i get all others | 07:29.21 |
| ok | 07:29.25 |
| i've changed my desktop computer | 07:29.35 |
tor8 | well, it ain't there | 07:29.43 |
vtorri | but it's quite recent and i want to install archlinux | 07:29.59 |
| problem is : my mother board is UEFI and installing arc with UEFI is quite... complicated | 07:30.21 |
| arch* | 07:30.26 |
tor8 | http://ghostscript.com/~tor/stuff/manual.pdf.outline.txt | 07:30.50 |
| that's the outline | 07:30.55 |
vtorri | tor8, also, the TOC of the PDF shows only section 10, nut the outline also gives subsections. is it normal ? | 07:31.10 |
| ok | 07:31.28 |
| i have the same | 07:31.32 |
| thanks | 07:31.36 |
tor8 | the table of content page has no relation (other than what the author intended) to the outline | 07:31.45 |
vtorri | ok | 07:31.51 |
| i thougt it was the same | 07:31.57 |
tor8 | vtorri: you ought to at least skim through the PDF reference to get an idea of what's possible and not in the PDF format. IMO. | 07:32.45 |
vtorri | hehe | 07:32.56 |
| it's a big manual :) | 07:33.07 |
| i have downloaded it | 07:33.14 |
tor8 | but pick the 1.3 version, it's a lot smaller :) | 07:33.14 |
vtorri | ha | 07:33.21 |
| i have to find it then | 07:33.27 |
| 518 pages... | 07:34.00 |
| arg | 07:34.03 |
tor8 | http://partners.adobe.com/public/developer/en/pdf/PDFReference13.pdf | 07:34.10 |
vtorri | and 700 for your version :) | 07:34.46 |
tor8 | of which you only need to read like 50 pages to get the basics, the rest is details and tables | 07:35.30 |
vtorri | tor8, another question : for the goto link, is there a correct use of lt and rb and the flags somewhere ? | 07:35.47 |
| te doc in fitzh.h is not very detailed | 07:36.20 |
| the* | 07:36.23 |
| those 2 points define a rectangle | 07:37.29 |
tor8 | vtorri: read table 7.2 (page 386) of pdf reference 1.3 and it should become clear what the flags do | 07:38.21 |
vtorri | if the flags are such that lt and rb are in the pdf, there is no problem, if have correctly understood | 07:38.24 |
| but if they are not in pdf, what to do ? | 07:38.43 |
tor8 | you can always just go the the page specified. I personally hate when the zoom factor changes because you follow a link, as the spec would have it... | 07:40.24 |
| but the spec only looks like that because it's what acrobat does | 07:40.40 |
vtorri | ok | 07:41.37 |
| so your advice would be : forget about that and consider only the page | 07:41.51 |
tor8 | yeah. | 07:42.07 |
| if you do consider the "display window" as the spec calls it, I fear you may run into a bug/misfeature | 07:42.33 |
vtorri | ok | 07:43.06 |
| and less code for me :) | 07:43.15 |
tor8 | the coordinates may be in a different coordinate space than they should. I believe there's an entry in bugzilla for it. | 07:43.16 |
| it's simpler (and better for the user) if you ignore most of it and just use the page and 'top' value | 07:43.41 |
vtorri | ok | 07:43.59 |
| and it makes sense, indeed | 07:44.18 |
tor8 | Robin_Watts: speaking of that bug, any idea for how to solve it? we need to load and resolve the page mediabox and rotation to properly compensate for it. | 07:44.45 |
vtorri | thank you | 07:44.49 |
tor8 | maybe we should add an accessor function to read out the display window given the link and pdf_page object? | 07:45.05 |
Robin_Watts | tor8: I haven't thought about it. | 08:41.20 |
| tor8: Do you want to look over the openjpeg2 changes? | 09:05.18 |
tor8 | on robin/OpenJEG2 ? | 09:06.26 |
Robin_Watts | tor8: yeah. | 09:06.33 |
| And on openjpeg.git/zeniko_fixes | 09:06.47 |
vtorri | why do you need openjpeg v2 ? | 09:06.59 |
tor8 | the -DOPJ_STATIC etc, should we really have those affect the global CFLAGS? | 09:07.03 |
vtorri | isn't v1 sufficient ? | 09:07.09 |
tor8 | (in your makefile changes) | 09:07.13 |
Robin_Watts | tor8: Shelly moved the OPJ_STATIC definition to the makefile from fitz/image_jpx.c. | 09:07.53 |
| I put it back into fitz/image_jpx.c | 09:08.02 |
| but it's arguably nicer in the makefile. | 09:08.24 |
tor8 | Robin_Watts: I'm talking about all the -D in Makethird | 09:08.52 |
Robin_Watts | It should be defined for everything that even includes the header, hence the global CFLAGS is not a bad place for it. | 09:08.58 |
tor8 | we could have override rules in the main Makefile for image_jpx.o only to use OPENJPEG_CFLAGS or something like that | 09:09.23 |
| so we don't put a ton of flags on all files, whether they need it or not | 09:09.42 |
Robin_Watts | tor8: I would personally think it was better to leave it. | 09:10.03 |
tor8 | the -D stuff doesn't work on the win32 build | 09:10.07 |
Robin_Watts | indeed not. | 09:10.14 |
| The way it works on windows is a bit of a hack. | 09:10.30 |
tor8 | so we still need an answer for that. | 09:10.36 |
Robin_Watts | We define it just for the header inclusion from image_jpx.c, which turns out to be all that it actually matters for. | 09:10.53 |
tor8 | I *don't* want crap like -DHAVE_INTTYPES_H on *all* our source files | 09:10.57 |
| god knows what effect that can have on the other thirdparty libraries, now and in the future | 09:11.22 |
Robin_Watts | Well, we could drop the makefile stuff entirely if you prefer and rely on the same hack. | 09:11.29 |
tor8 | Robin_Watts: I would put those back on the $(CC_CMD) specifically for the openjpeg files | 09:11.47 |
| and then put the same in image_jpx.c as a hack (so it'll work on win32 and android) | 09:12.03 |
| or put them in an OPENJPEG_CFLAGS variable, and have a specific rule to build image_jpx.o with that variable | 09:12.25 |
Robin_Watts | tor8: Can you make me a patch? Then I'll test it etc. | 09:12.27 |
tor8 | Robin_Watts: I will | 09:12.33 |
Robin_Watts | thanks. | 09:12.38 |
tor8 | I'll just go through the rest | 09:12.40 |
Robin_Watts | I'll pull zenikos latest fix in too. | 09:12.47 |
tor8 | so we're on their trunk rather than the tagged 2.0? | 09:13.01 |
Robin_Watts | tor8: We're somewhere ahead of the tag, certainly. | 09:14.03 |
tor8 | bug 693503: infinite loop. why extra if condition, if (len <= 0) return -1; should work no? | 09:14.10 |
| and casting -1 to an unsigned value ... is that even safe? | 09:14.33 |
vtorri | yes | 09:15.03 |
Robin_Watts | tor8: where? | 09:15.29 |
tor8 | vtorri: yes to what? | 09:15.33 |
| Robin_Watts: return (OPJ_SIZE_T)-1 | 09:15.39 |
vtorri | it is safe | 09:15.43 |
Robin_Watts | tor8: where are you looking at the openjpeg changes? which commit ? | 09:15.46 |
tor8 | bug 693503: infinite loop commit | 09:15.55 |
Robin_Watts | is this in openjpeg or in mupdf ? | 09:16.02 |
tor8 | mupdf | 09:16.04 |
vtorri | the sign is just a bit in the binary representation of the integer | 09:16.08 |
| the last one, iirc | 09:16.25 |
tor8 | vtorri: I'm not asking about whether the C language is okay, I'm wondering what the surrounding code will do | 09:16.28 |
vtorri | ho :) | 09:16.36 |
| :p | 09:16.39 |
| but the C langage os ok :p | 09:16.56 |
| is* | 09:17.02 |
Robin_Watts | tor8: I believe that's what the stream_read thing is supposed to do. | 09:17.18 |
tor8 | stream_read returns an unsigned value... | 09:18.08 |
| (unless OPJ_SIZE_T is not the same as size_t) | 09:18.22 |
| so the question is, will the caller of stream_read do the right thing? | 09:19.18 |
Robin_Watts | Look at cio.c line 310 | 09:20.06 |
| p_stream->m_bytes_in_buffer = p_stream->m_read_fn(p_stream->m_stored_data,p_stream->m_buffer_size,p_stream->m_user_data); | 09:20.19 |
| if (p_stream->m_bytes_in_buffer == (OPJ_SIZE_T)-1) { | 09:20.28 |
| /* end of stream */ | 09:20.30 |
| I believe returning (OPJ_SIZE_T)-1 is exactly what that routine is SUPPOSED to do when you hit the end of the file. | 09:20.56 |
| returning 0 is wrong; it means "I read no bytes this time, but you might get more later" | 09:21.17 |
tor8 | Robin_Watts: right, they cast (OPJ_SIZE_T)-1 in their test as well so that should be good then | 09:22.00 |
| just seemed an odd and rather dangerous thing to do, to use size_t and still have "negative" in band error codes | 09:22.31 |
| Robin_Watts: all fixes look good to me. are we going to ask for them to be integrated upstream? | 09:26.54 |
| in that case it may be worthwhile not pushing the mupdf fixes until we can rebase so our thirdparty is tracking upstream's master | 09:27.19 |
Robin_Watts | tor8: We publish our fixes on a different branch. | 09:29.49 |
| the git submodule is only an SHA record, so jumping around between branches doesn't hurt us. | 09:30.29 |
| and IME, openjpeg are awkward about taking fixes. | 09:30.51 |
| but yes, we should offer them. | 09:30.56 |
vtorri | robin_watts: open a ticket and just see the answers | 09:39.38 |
tor8 | Robin_Watts: as long as the branch on our openjpeg.git stays alive so the commits don't get garbage collected | 09:46.28 |
Robin_Watts | tor8: It's named 'zeniko_fixes' at the moment, so it can't be gc'd. | 09:47.10 |
tor8 | Robin_Watts: yeah. but when the fixes get integrated into mainline, we don't want a "stale" branch sitting around. | 09:47.40 |
| maybe a tag will save it from being collected as well though | 09:47.51 |
Robin_Watts | tag and branches are all the same in git, right? | 09:48.07 |
tor8 | consider the scenario where upstream takes on the fixes, but not as is, and then we can move our openjpeg submodule to their new release | 09:48.29 |
| and then zeniko_fixes gets collected, and git bisect will break because it can't find the commits | 09:48.53 |
Robin_Watts | tor8: Then we leave a tag (or a branch) pointing to the old one. | 09:49.00 |
tor8 | Robin_Watts: yeah. they're both just pointers. so we'll have to leave a tag or branch pointing to them so they're kept alive | 09:49.13 |
vtorri | if I have a rectangle defines by (x0, y0) and its width and height, are x1 and y1 of an fz_rect defined by x0+width and y0+height resp. ? | 09:49.26 |
| or should I add 1 ? | 09:49.40 |
Robin_Watts | vtorri: If you have a rectangle defined as (x0, y0) (x1, y1) then (x1,y1) is just outside the rectangle. | 09:50.15 |
vtorri | ok | 09:50.24 |
Robin_Watts | i.e. width = x1 - x0, height = y1-y0 | 09:50.28 |
tor8 | we're using git-svn to pull in upstream openjpeg so I don't think we have anything to worry about keeping our mirror of openjpeg pristine and in sync | 09:50.32 |
vtorri | thank you | 09:50.39 |
Robin_Watts | tor8: 1 final fix added to that branch. | 09:54.13 |
| with those in, we get MUCH closer to running clean on the fuzzing tests. | 09:54.29 |
| I have a doctors appointment, so bbl. I'll look at Shellys jbig2dec fix, and test the failures from marcosw's run. | 09:56.10 |
vtorri | when i'm extracting text from a PDF, should I save a text_seet and/or text_page for further text extraction (for speed) ? | 09:59.43 |
tor8 | Robin_Watts: I'm off for lunch soon. I'll poke at the makefile when I get back, so don't push the mupdf changes yet. | 10:00.11 |
vtorri | hmm, certainly not text_page | 10:02.22 |
Robin_Watts | vtorri: Only if it will save you repeatedly extracting from the same page. | 10:56.38 |
vtorri | ok, thanks | 10:56.53 |
Robin_Watts | Who owns jbig2dec ? | 11:30.12 |
chrisl | Robin_Watts: I think henrys officially jbig2dec | 11:34.43 |
| s/officially/officially owns | 11:35.29 |
| I would note that Tor's script for mirroring changes from ghostpdl repo into jbig2dec repo isn't working | 11:36.09 |
vtorri | afaik, ghostscript can render PDF. Why isn't ghostscript using mupdf for that ? | 11:43.29 |
Robin_Watts | vtorri: acrobat can render PDF too. Why isn't that using ghostscript? | 11:44.18 |
vtorri | sorry, but my question makes sense as : | 11:44.43 |
| 1) you are under artifex umbrella | 11:44.58 |
| 2) that could factorise ghostscript code | 11:45.17 |
| 3) make in common several developpers working on the same kind of stuff | 11:45.37 |
| and i guess you know each other | 11:45.45 |
Robin_Watts | there have been thoughts in the past about combining mupdf and ghostscript in some way. | 11:45.49 |
| and some prototype code exists. | 11:46.01 |
| but it's not a trivial thing. | 11:46.05 |
vtorri | sure | 11:46.14 |
| see, i also asked the same thing to poppler devs and xpdf some years ago, as poppler is a fork of xpdf code | 11:47.03 |
| and they basically say the same thing | 11:47.35 |
| not a trivial thing | 11:47.41 |
| but that could save so much work and make development so much faster | 11:48.02 |
| i see GhostPDF, GhostXPS | 11:48.34 |
| and i know that mupdf also support XPS | 11:48.43 |
| really i don't understand | 11:48.55 |
Robin_Watts | vtorri: The XPS specific code in mupdf is pretty much the same. | 11:49.11 |
| I mean GhostXPS = some XPS parsing code + the gs graphics library. | 11:49.36 |
| that same XPS parsing code is the MuPDF XPS parsing code. | 11:49.56 |
| But the underlying graphics libraries in ghostscript and mupdf are very different. | 11:50.19 |
| trying to take code that has been written for one and use it on the other is not necessarily a good fit. | 11:50.56 |
chrisl | vtorri: different products, different target audiences, different market segments | 11:51.03 |
Robin_Watts | Think of the GS graphics lib as being like a truck engine, and the GS parsing code as being like an articulated lorry. | 11:51.55 |
| Then think of mupdf as being a ferrari. | 11:52.06 |
| Trying to put a truck engine in a ferrari, or a ferrari engine in a truck will have problems. | 11:52.24 |
vtorri | different target audience, yes, but if mupdf is a library on its own ( == if it's a shared lib), then it's not a problem | 11:52.43 |
Robin_Watts | The truck is very powerful, and can cope with carrying all sorts of things on all sorts of road surfaces. | 11:53.07 |
| The ferrari is much faster than the truck, but only really works for specific loads on specific surfaces. | 11:53.33 |
chrisl | vtorri: it is a problem: ghostscript/ghostpdl is primarily focussed on printing and workflow applications, mupdf is primarily screen based. | 11:53.43 |
vtorri | robin_watts: i like the comparison :) | 11:54.00 |
| chrisl, ok | 11:54.10 |
| anywa, thanks for your remarks | 11:54.21 |
| :) | 11:54.24 |
| it's clearer for me :) | 11:54.36 |
chrisl | vtorri: it's two products that evolved separately with very different design remits - trying to mash them together later is possible, but often nightmarish | 11:55.02 |
vtorri | from wat i've understood, writing ghostscript from scratch with mupdf in mind would be necessary | 11:56.17 |
| as merging mupdf seems not possible or not efficient | 11:56.50 |
chrisl | Pretty much - we'd have to re-engineer the Postscript interpreter almost entirely, and *probably* re-engineer large parts of fitz to cope, too | 11:57.19 |
Robin_Watts | We would not make the gs parser call mupdf. | 11:57.41 |
| We might be tempted to make the mupdf parser call the gs graphics engine (in fact, we have some code somewhere that tries to do this). | 11:58.07 |
| but it's not trivial, and it's not a smooth fit in all cases. | 11:58.20 |
vtorri | gs engine helped me, btw | 11:59.15 |
| to render postscript and dvi files :) | 11:59.26 |
| libgs, actually | 11:59.45 |
chrisl | I don't think we do dvi | 12:00.09 |
Robin_Watts | we don't, but I bet he uses dvips to get ps. | 12:00.28 |
chrisl | That would work | 12:00.38 |
vtorri | yes | 12:05.14 |
| the only problem i have with ps is getting the informations of the document | 12:08.03 |
| except parsing the postscript file, i don't see how to do that | 12:08.21 |
chrisl | vtorri: you can't, that's the way Postscript works | 12:08.37 |
| vtorri: in some cases, you can use the DSC comments, but they are not required in Postscript, and frankly, are sometimes wrong | 12:09.22 |
vtorri | ok | 12:09.31 |
| so parsing the file :/ | 12:09.36 |
chrisl | You could convert to PDF, and just deal with the PDF | 12:09.59 |
vtorri | hmm | 12:11.33 |
| mupdf can do that ? | 12:11.48 |
Robin_Watts | no, but gs can. | 12:12.43 |
| but be aware that the conversion is not always a lossless process. | 12:13.03 |
vtorri | i'm aware of that | 12:14.43 |
chrisl | It's generally a pretty accurate conversion from PS to PDF, it's PDF->PDF where the loss of metadata can be a problem | 12:16.25 |
| Aha, tor8 - I've been meaning to mention that ghostpdl/gs/jbig2dec changes aren't getting mirrored to the jbig2dec repo | 12:18.19 |
tor8 | chrisl: odd... | 12:22.49 |
| it works if I run my script manually | 12:22.55 |
chrisl | tor8: that is odd - I wonder if the environment is different from cron | 12:23.48 |
tor8 | chrisl: ah. cron is running with a different $PATH | 12:24.22 |
| so no git-subtree | 12:24.25 |
chrisl | That could be a problem :-) | 12:24.42 |
tor8 | should be fixed now | 12:25.01 |
chrisl | That's "good" - it removes an excuse for putting of a jbig2dec release :-( | 12:25.59 |
vtorri | chrisl, what is the status of jbig2dec wrt to be a shared lib ? | 12:26.43 |
chrisl | vtorri: *we* don't maintain it as such, but will accept patches | 12:27.17 |
vtorri | seriously ? | 12:28.40 |
chrisl | Huh? | 12:29.03 |
vtorri | i'll give some patches, then :) | 12:29.52 |
| well, me memory is maybe not the best, but i remember that you changed your mind about that | 12:30.19 |
| maybe i'm wrong | 12:30.59 |
chrisl | We had planned to kill it as a product in its own right, but there was some resistance to idea - for reasons I can't quite fathom | 12:31.22 |
vtorri | hehe | 12:33.05 |
| still using the autotools | 12:33.11 |
| i filed a bug some time ago | 12:33.34 |
| 691784 | 12:34.02 |
chrisl | Hrm, I thought I'd applied that one | 12:35.00 |
vtorri | the bug is still open | 12:35.16 |
chrisl | Oh, actually, it looks like the -no-undefined was added as part of another patch | 12:36.43 |
vtorri | whic version of autotools do you support ? | 12:39.31 |
chrisl | Whatever is on my computer ;-) Actually, we're currently sticking to 2.52, I think | 12:40.32 |
vtorri | omg | 12:41.37 |
| autogen.sh is quite complicated :p | 12:41.45 |
| "autoreconf -vif" should be sufficient for autotols detection | 12:42.21 |
| and their call | 12:42.37 |
chrisl | <shrug> I didn't write it | 12:45.37 |
vtorri | ok | 12:47.50 |
| chrisl, if i provide patches, do you prefre small patches ? | 12:48.18 |
chrisl | vtorri: yes, that would be better | 12:48.56 |
vtorri | chrisl, and i open bugs with them attached ? | 12:51.50 |
chrisl | vtorri: of, if they are all fairly closely related, you can open one bug, and attach patches to that | 12:52.35 |
vtorri | ok | 12:52.50 |
chrisl | vtorri: you should grab the code from the ghostpdl git repo and patch against that - it is always the most up to date | 12:53.31 |
vtorri | chrisl, so not taht one : http://git.ghostscript.com/?p=jbig2dec.git ? | 12:54.08 |
chrisl | vtorri: you can use that one, there is just a slight delay because changes are mirrored from the ghostpdl repo to that one | 12:55.06 |
vtorri | ok | 12:55.13 |
chrisl | Basically http://git.ghostscript.com/?p=ghostpdl.git;a=summary is the canonical repo, and http://git.ghostscript.com/?p=jbig2dec.git pulls changes in from there | 12:55.56 |
vtorri | ok | 13:02.38 |
henrys | chrisl Robin_Watts jbig2dec is alexcher - and that is something I wanted to bring up at the meeting, it would be good if he were managing shelly and simon's changes. | 13:07.18 |
Robin_Watts | henrys: OK. | 13:07.41 |
| http://bugs.ghostscript.com/show_bug.cgi?id=694021 contains a fix from shelly for jbig2dec that's been around for a couple of weeks. | 13:08.24 |
henrys | alexcher for the logs ^^^ | 13:10.22 |
| Robin_Watts:I put it on my pointy haired todo list also, so I'll remind him if we don't hear soon. | 13:12.14 |
Robin_Watts | ok. Who is responsible for openjpeg in gs ? | 13:12.35 |
| mupdf uses its own openjpeg repo, so if we take on patches from Shelly/Simon that does affect gs. but it would make sense to push them back into gs (assuming gs is using openjpeg 2 too) | 13:14.01 |
henrys | Robin_Watts: right I wish it wasn't so, but right. | 13:15.34 |
Robin_Watts | henrys: which bit do you wish wasn't so? | 13:15.58 |
| that we were using openjpeg 2? | 13:16.06 |
henrys | Robin_Watts: 2 repos | 13:16.20 |
Robin_Watts | Right. | 13:16.26 |
| Well, if we can get all the mupdf fixes into gs, then we can do the same extraction trick as we do with jbig2dec. | 13:16.57 |
henrys | Robin_Watts:is there any upstream discussion in place he should know about. | 13:17.11 |
| ? | 13:17.12 |
Robin_Watts | We have not proffered them upstream yet. | 13:17.27 |
chrisl | Well, if they ever get to the stage where git submodules (or whatever they are called) are seemless, then we can consolidate the gs and mupdf third party libs | 13:18.06 |
| or even seamless..... | 13:18.29 |
Robin_Watts | chrisl: We'd have to have a break in the history to do that. | 13:19.11 |
chrisl | At least for the genuine third party libs, do we care? | 13:19.40 |
Robin_Watts | i.e. at some point we'd need to delete the contents of the libs, and import the submodule. | 13:19.40 |
| At that point, it becomes hard to bisect across that gap. | 13:19.56 |
chrisl | I'd have thought if the submodule stuff was actually seamless, bisect would "just work" (tm) | 13:20.37 |
tor8 | chrisl: it's almost there, but there are issues with submodules appearing and disappearing and it not wanting to zap the submodule git | 13:21.15 |
Robin_Watts | bisecting within a range of commits within the lifetime of a submodule isn't a problem. | 13:21.38 |
| bisecting back past the point where the submodule appeared, is I suspect, trickier. | 13:22.01 |
chrisl | tor8: right, and things like cloning and pulling etc I would expect to be one step, instead of the current, as I understand it, two step process | 13:22.25 |
tor8 | Robin_Watts: git refuses to clobber the existing directory when doing that (at least it does with normal checkouts) | 13:22.31 |
| chrisl: clone --recursive takes care of that | 13:22.44 |
| and "git remote update" does the right thing for submodules | 13:22.58 |
Robin_Watts | tor8: urm... no. | 13:23.05 |
tor8 | so it's pretty painless with recent gits | 13:23.08 |
| Robin_Watts: no? | 13:23.20 |
Robin_Watts | With git bisect you need to remember to "git submodule update" at each stage, right? | 13:23.31 |
chrisl | tor8: but I don't consider that "seamless" - I'd want it to "just work" without extra options/operations | 13:23.41 |
Robin_Watts | and after every pull you need to "git submodule update" again. | 13:23.42 |
| and there is no room in the git way of working for every commit to the main module to automatically include commits to the submodule. | 13:24.30 |
| There is always going to be a small amount of discontinuity there. | 13:24.44 |
chrisl | tor8: I'm just thinking of the knots that Ray and Michael manage to create/find with a "flat" repo, and until submodules are entirely transparent to the "normal" user, I'd be wary of using them in ghostpdl. | 13:26.45 |
tor8 | chrisl: agreed. I'd stay away from them in ghostpdl too for the same reason. | 13:27.47 |
| they do require a grasp of the git inner workings to make sense | 13:28.01 |
henrys | amazing to me how third party code is so fundamental to any software project but seems to be an afterthought in every version control system I've used. | 13:28.05 |
tor8 | third party software is supposed to be stable and done and never need to update, right? ;) | 13:28.39 |
Robin_Watts | henrys: I'm yet to be convinced that the git submodule system isn't in fact exactly ideal. | 13:28.53 |
| Thirdparty code that you import to a project should NOT be treated like local code. | 13:29.36 |
tor8 | the concept of git submodules is IMO one of the better. it's just not always easy to work with the tools, but that's more to do with the fact that third party dependencies are fraught with problems in and of itself, not due to git | 13:29.49 |
Robin_Watts | changes to that code should happen independently of changes to the local code. | 13:30.14 |
| and yet changes to the local code should be introduced at exactly the same time as changes to the thirdparty code are introduced. | 13:30.47 |
| git submodules achieves all of that. | 13:30.56 |
chrisl | Robin_Watts: committing/pushing to third party code should be clearly separated from local code, but just cloning/pulling/bisecting really should be transparent | 13:36.49 |
henrys | If any of this is correct it sounds bad:http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ | 13:37.09 |
Robin_Watts | chrisl: There are times when you don't want the atomic cloning/pulling/bisecting. | 13:37.48 |
| but I'll admit that those should be the outlier cases rather than the defaults. | 13:38.04 |
chrisl | henrys: oh, and did you see that google code is stopping hosting downloads? So much for keeping that one active! | 13:38.29 |
henrys | chrisl:wow that and google reader is gone what next? | 13:38.57 |
tor8 | chrisl: and they're killing google talk. they're really on a "let's turn everything to shit and flush it down the toilet" spree. | 13:39.09 |
chrisl | henrys: they might start paying tax?? | 13:39.22 |
henrys | the reality of having shareholders may be sinking in. | 13:39.57 |
chrisl | Robin_Watts: I think the tools for "fiddling" with submodules should be available, but for most users they should disappear entirely into the background | 13:40.13 |
henrys | chrisl:I was going to tell miles we should set up in Ireland. | 13:40.16 |
| right next to google and apple | 13:40.30 |
tor8 | henrys: the article on that link ... he's not using submodules as intended. for thirdparty stuff submodules are good, for internal modules of code not so much | 13:40.42 |
chrisl | henrys: I'm sure there's a spare P.O box somewhere in Ireland | 13:41.03 |
Robin_Watts | henrys: The caymans is possible too. | 13:41.05 |
| We could have staff meetings at head office :) | 13:41.14 |
tor8 | from what I understand he's done the equivalent of splitting the "psi" and "xps" and "common" directories of ghostpdl inte submodules | 13:41.14 |
Robin_Watts | I got a fraud prevention call from my card company recently, asking me to identify transactions and say whether they were mine. | 13:42.15 |
| "A bookshop based in Luxemburg" | 13:42.36 |
| "A chemical and aggregated goods company based in Luxemburg" | 13:43.02 |
| That'll be Amazon and Ebay then. | 13:43.11 |
henrys | I'm all for submodules but against ruffling michael and ray feathers and it seems tripping over stuff will be inevitable. | 13:43.52 |
chrisl | Robin_Watts: my credit card company did that after the last staff meeting - based on the purchase of a $4 bottle of pop from a vending machine! | 13:44.25 |
Robin_Watts | chrisl: Well, you are scottish :) | 13:44.40 |
chrisl | Very true! | 13:44.55 |
henrys | Robin_Watts:have you seen Helen recently? | 13:45.07 |
| :-) | 13:45.40 |
Robin_Watts | not since lunch. | 13:45.41 |
| henrys: I discovered the secret of a successful marriage ages ago - separate bank accounts. | 13:46.06 |
kens | We've always had separate acounts | 13:46.22 |
| When Stella stopped working I set up a standingroder form my accoutn to hers | 13:46.36 |
Robin_Watts | I never need to know how much she spent on shoes, hair, makeup, and she never needs to know how much I spend at amazon. | 13:47.11 |
henrys | we watch what each other buys on mint and then fight - much more entertaining. | 13:47.16 |
| mint pops the transaction up right up on my desktop: shoes, shoes, shoes, clothes, shoes â¦. it's like being punched in the stomach repeatedly. | 13:49.18 |
Robin_Watts | hehe | 13:49.44 |
henrys | btw monday is a US holiday. | 13:59.08 |
kens | Here too | 13:59.16 |
henrys | spring bank? | 14:00.00 |
chrisl | henrys: yes | 14:01.04 |
henrys | odd name - just reading about it. | 14:01.22 |
chrisl | Well, they are called "bank holidays", and this is the spring one | 14:01.50 |
Robin_Watts | tor8: hey. Did you get a chance to do the makefile tweaks? | 16:26.37 |
tor8 | Robin_Watts: working on it | 16:26.46 |
Robin_Watts | ok. | 16:26.50 |
kens | Night all | 16:29.25 |
tor8 | fitz/image_jpx.c:123:3: warning: 'opj_stream_destroy' is deprecated | 16:32.12 |
| Robin_Watts: ^ | 16:32.14 |
Robin_Watts | tor8: yeah. Stupid openjpeg. | 16:32.44 |
vtorri | is there an example of text extraction of a rectangle (and not the entire page) ? | 16:32.51 |
Robin_Watts | Your choices are opj_stream_destroy or opj_stream_destroy_v3 | 16:33.05 |
vtorri | Robin_Watts: +1 | 16:33.07 |
Robin_Watts | but _v3 casts the m_user_data to a FILE * and fcloses it. | 16:33.37 |
| so we have no alternative but to call the old version. | 16:33.49 |
tor8 | Robin_Watts: oh... | 16:33.49 |
| that's. stupid. | 16:33.54 |
Robin_Watts | and the old version is EXACTLY the same as the _v3 version except without the fclose. | 16:34.04 |
| so we just ignore the deprecation. | 16:34.13 |
tor8 | Robin_Watts: what to do about OPJ_STATIC in image_jpx.c? leave it in for windows? | 16:35.09 |
Robin_Watts | tor8: I'd leave it in with the comment explaining it. | 16:36.50 |
tor8 | does HAVE_INTTYPES etc work automatically on windows? | 16:37.18 |
Robin_Watts | Our Mupdf customer is successfully using the pdfclean code to save out pages from their DRMd books for printing. | 16:37.28 |
vtorri | no | 16:37.29 |
| there is no HAVE_*** on Windows | 16:37.50 |
Robin_Watts | tor8: I don't think we set it in the project files. | 16:37.51 |
vtorri | you have to define them | 16:37.56 |
| HAVE_** is usually an autoconf stuff | 16:38.10 |
Robin_Watts | vtorri: yes, we know. Tor was asking about specific build stuff. | 16:38.30 |
tor8 | vtorri: I'm asking specifically about openjpeg, whether it has ifdefs to deal with it or if they expect HAVE_INTTYPES. | 16:38.32 |
Robin_Watts | tor8: It is not needed for windows. | 16:39.09 |
tor8 | Robin_Watts: right. it builds on mac with only -DOPJ_STATIC and -DOPJ_HAVE_STDINT_H the others are not needed there. | 16:39.37 |
| just going to test the same on linux | 16:39.41 |
vtorri | see opj_inttypes.h | 16:40.25 |
tor8 | Robin_Watts: hah. -DOPJ_STATIC is also unneeded | 16:41.58 |
Robin_Watts | tor8: in unix, possibly, yes. | 16:42.14 |
tor8 | better leave it in though | 16:42.39 |
Robin_Watts | unless there is some strange toolchain that mangles __stdcall | 16:42.44 |
| that was my thought. | 16:42.53 |
tor8 | I recall there being something causing problems without OPJ_STATIC on 1.5 and earlier builds | 16:43.21 |
| Robin_Watts: okay, patch on tor/openjpeg2 | 16:46.47 |
| question is, we can drop the special rule in Makefile by putting the #defines in image_jpx.c, but I suspect it's better to keep them in the makefie | 16:47.20 |
| makefile. damn keyboard. | 16:47.25 |
Robin_Watts | thanks. | 16:47.43 |
| tor8: Can we drop them? | 16:47.55 |
tor8 | Robin_Watts: feel free to rebase it down if you want | 16:47.55 |
vtorri | is there an example of text extraction of a rectangle (and not the entire page) ? | 16:48.11 |
tor8 | Robin_Watts: sorry, I don't follow you. drop what? | 16:48.21 |
| vtorri: why would you want to? | 16:48.27 |
vtorri | to extract a part of the page <? | 16:48.53 |
Robin_Watts | tor8: Can we get away with putting the #defines in image_jpx.c? | 16:49.27 |
tor8 | vtorri: you can pass a "clipping" rectangle to fz_run_page / display_list, but it will still capture any text object that even partially touches the rectangle | 16:49.32 |
Robin_Watts | I mean, we *can* for windows. | 16:49.33 |
tor8 | vtorri: why would you want to? | 16:49.39 |
Robin_Watts | But can we for linux? | 16:49.40 |
tor8 | Robin_Watts: yeah. both macosx and linux have stdint.h | 16:49.54 |
vtorri | if i select with a mouse some rectangle on a page, i want to retrieve the text of that selection | 16:50.28 |
Robin_Watts | Putting HAVE_STDINT in image_jpx.h would help with the inclusion of the header for that file. | 16:50.45 |
tor8 | so it's only a #ifdef _WIN32, define OPJ_STATIC, define OPJ_HAVE_STDINT_H, endif | 16:50.45 |
| vtorri: see fz_highlight_selection, fz_copy_selection | 16:51.09 |
Robin_Watts | It would not define HAVE_STDINT for the actual building of the lib. | 16:51.19 |
tor8 | Robin_Watts: we'd still need the special macros for building the lib, but we'd be spared the special rule for image_jpx.o | 16:51.37 |
Robin_Watts | Oh. I see, you have a special rule. | 16:51.52 |
| I dislike special rules. | 16:52.16 |
| Personally, I'd rather have OPJ_HAVE_STDINT_H as a CFLAG everywhere. | 16:52.44 |
| It's got an OPJ_ prefix, so it won't clash. | 16:52.57 |
| and it means if we ever add another file that uses OPJ stuff ,we won't forget to add the special rule there. | 16:53.21 |
tor8 | Robin_Watts: pull tor/openjpeg2 to see what I mean we can do instead | 16:54.34 |
| if you like that better, squish 'em | 16:54.43 |
Robin_Watts | yeah, I follow that. | 16:56.32 |
| I can't help but think that it would be nicer to just have a global OPJ_HAVE_STDINT_H flag passed around everywhere. | 16:56.56 |
vtorri | fz_copy_selection does not take into account the lines | 16:56.57 |
| and with my example, it adds '1' at the end of the string | 16:57.16 |
Robin_Watts | but I could live with this. | 16:57.20 |
tor8 | I've seen projects where you end up with fifteen lines of -D and -I flags to build. not fond of that. | 16:57.42 |
Robin_Watts | vtorri: Are you copying from page 1 of a PDF? | 16:57.53 |
tor8 | would rather have special rules for each source file that needs an external header | 16:57.58 |
vtorri | robin_watts: yes | 16:58.04 |
Robin_Watts | Sometimes PDFs have 'hidden' text with the page number on them. | 16:58.14 |
vtorri | or... | 16:58.24 |
| ho | 16:58.26 |
| maybe the rectangle touches the page number | 16:58.37 |
Robin_Watts | maybe. | 16:58.43 |
vtorri | which is actaully 1 | 16:58.44 |
Robin_Watts | tor8: OK, so new version on robin/openjpeg2 | 17:06.06 |
| if you're happy, I'll push that. | 17:06.21 |
| 3 commits ready to go on robin/master too. | 17:09.37 |
| The Android overdraw ones have been looked at by me and paulgardiner from monxalo's original, so that's been reviewed already, I guess. | 17:10.15 |
| the android makefiles one just allows for the fact we now have 1 lib rather than 2 for v8 (and we have it for all archs). | 17:10.47 |
tor8 | Robin_Watts: forgot to zap the special rule in Makefile | 17:13.22 |
| the "File specific overrides" section | 17:13.34 |
Robin_Watts | try now ? | 17:14.38 |
tor8 | Robin_Watts: looks good. | 17:28.03 |
vtorri | tor8, is it normal that, if I select 2 line, fz_copy_selection does not insert \n after the end of the 1st line ? | 17:28.18 |
Robin_Watts | And the 3 on robin/master? | 17:28.19 |
| vtorri: Yes. | 17:28.32 |
vtorri | ok | 17:28.36 |
| and fz_highlight_selection orders the boxes from the bottom to the top ? | 17:29.20 |
tor8 | Robin_Watts: redraw I looked at before. did you fix the Color.TRANSPARENCY and invalidate stuff you and monxalo talked about the other day? | 17:29.23 |
Robin_Watts | I did. | 17:29.31 |
| The ImageMask one works, but sometimes gets the sense of the mask inverted. | 17:31.09 |
tor8 | Robin_Watts: what is the colors argument to fz_image_as_png for? | 17:31.19 |
Robin_Watts | If you show an image mask you give it a colorspace and a color. | 17:31.47 |
| In the case where you're feeding an imagemask to fz_image_as_png you need that too. | 17:32.14 |
tor8 | to colorize the mask with the fill color? | 17:32.28 |
Robin_Watts | To fix the inversion, we'd need to include a decode array. | 17:32.29 |
| yeah. | 17:32.32 |
tor8 | hm. how about a separate call to colorize a mask image, so we don't need to put that in the png api? | 17:33.00 |
Robin_Watts | tor8: That might be nicer. | 17:33.12 |
| oh, no. | 17:33.29 |
| The problem is we don't colorise images, we colorize pixmaps. | 17:33.39 |
tor8 | the other two (the android ones) on robin/master are good to go | 17:33.40 |
| my other thought would be a separate entry point for less confusion | 17:34.13 |
| fz_image_mask_as_png | 17:34.19 |
Robin_Watts | ok. I'll look at that. | 17:34.33 |
tor8 | the image_block->colors array, remind me what it contains | 17:35.46 |
Robin_Watts | tor8: The colors for an imagemask ? | 17:36.06 |
| the colors to colorise an imagemask with. | 17:36.15 |
tor8 | more than one color? | 17:36.16 |
Robin_Watts | float * innit, so 1 float per component. | 17:36.31 |
tor8 | imagemasks are always one component aren't they? | 17:36.33 |
Robin_Watts | tor8: right, but when colorised they go to image_block->mask_cs and that has multiple components. | 17:37.05 |
tor8 | I don't see a mask_cs entry in fz_image_block... | 17:39.04 |
Robin_Watts | image_block->colorspace ? | 17:39.17 |
tor8 | I see image_block-> image, cspace and colors | 17:39.34 |
Robin_Watts | cspace | 17:39.42 |
tor8 | image + cspace + colors -> colorized pixmap | 17:39.51 |
| to convert to png to dump in html | 17:39.58 |
Robin_Watts | right. | 17:39.59 |
tor8 | oughtn't it be: image + cspace + color (singular) | 17:40.31 |
| there's n components in the output colorspace, 1 component in the input space | 17:41.08 |
Robin_Watts | Imagine a imagemask that's filled in red on the output page. | 17:41.22 |
tor8 | the plural made me confused | 17:41.23 |
| block->image (grayscale), cspace (rgb) and colors (1,0,0) | 17:41.55 |
Robin_Watts | it was plural because there were multiple components of the color. | 17:42.04 |
| I think elsewhere in the code we use the plural. | 17:42.11 |
tor8 | or cmyk if a cmyk fill was used | 17:42.16 |
Robin_Watts | but I'm happy to change it to color. | 17:42.26 |
tor8 | multiple components of one color. if I've used colors with plural before it's because it's a lookup table of many colors. | 17:42.46 |
| (which is what I thought this was, hence my confusion) | 17:43.00 |
vtorri | fz_highlight_selection orders the boxes from the bottom to the top ? | 18:00.36 |
| Forward 1 day (to 2013/05/25)>>> | |