| | <<<Back 1 day (to 2016/10/09) | 20161010 |
| sebras | kens: good morning! | 06:44.27 |
| sebras | is off by less than 10 minutes! :) | 06:51.41 |
| kens | ? | 06:51.53 |
| sebras | kens: http://ghostscript.com/irclogs/current.html | 06:52.18 |
| kens | Ah :) | 06:52.36 |
| | Haven't got to the logs yet | 06:52.47 |
| sebras | kens: also now I know what time zone I have to be in to wake up at the same absolute time as you do. | 06:53.13 |
| kens | wonders if that is a good thing.... | 06:53.46 |
| Robin_Watts | sebras: p +n in your first commit looks unlikely to me. | 08:53.05 |
| | oh, wait, no, Ok. | 08:53.46 |
| sebras | Robin_Watts: I might be wrong. let me check. | 08:54.32 |
| Robin_Watts | sebras: No, looks good to me. | 08:54.59 |
| sebras | Robin_Watts: yeah, combined with your previous change it reverts to the old behaviour. | 08:55.13 |
| | Robin_Watts: but my patch on its own looks implausible, I agree. :) | 08:55.24 |
| Robin_Watts | All your commits look good to me then. | 08:56.02 |
| | There are 3 commits on robin/master ready to go. | 08:56.40 |
| | Then 2 to ignore. | 08:57.11 |
| | Then 4 more, that would be good to go if only I could fix the insertion of the 'A' stuff into html. | 08:57.36 |
| sebras | Robin_Watts: ok, I'll just push my own changes first! ;) | 08:57.38 |
| Robin_Watts | Do you understand the html parsing code (boxes vs flows etc) ? | 08:57.54 |
| sebras | Robin_Watts: I used to, but I'm not sure I can recall the details now. | 08:58.13 |
| Robin_Watts | I'll have to bug tor about it laterl. | 08:59.10 |
| sebras | Robin_Watts: the three first ones LGTM, but I haven't checked that the correct number of bits are used in each bitfield. | 09:09.43 |
| | Robin_Watts: then pool patch LGTM. | 09:11.54 |
| | Robin_Watts: in the list handling for epub patch though... | 09:13.24 |
| | Robin_Watts: in epub_parse_header(). will doc->spine really be set correctly? right. I see it now, *tail = epub_parse*(). | 09:14.04 |
| | Robin_Watts: what happeneds to the *s = 0 for #? | 09:14.33 |
| | Robin_Watts: that seems to be for a different patch? | 09:14.44 |
| Robin_Watts | oops, yes, will rejig. | 09:49.51 |
| | Updated patch online. | 09:54.33 |
| sebras | Robin_Watts: did you compile that? ;) | 10:17.27 |
| | Robin_Watts: you still remove the char *s variable. | 10:17.36 |
| Robin_Watts | sebras: crap. I just moved lines in the rebase. Will try again. | 10:17.57 |
| sebras | Robin_Watts: np. I'm happy that I caught it before I said LGTM though. :) | 10:18.25 |
| | Robin_Watts: tor8: now that both of you are here... | 10:46.04 |
| | I hope I got this one correct: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=blobdiff;f=source/fitz/font.c;h=b6e14656ee2e99ccf26f7028af80c4abf7141006;hp=6d86133cb7dc5f7c13e98b600b80a6ec17a9dbd9;hb=fa562f5ed6617b37636327356bd7653bdc39efa5;hpb=eb23fc80997bbb4409abe06a8392c0da4e445504 | 10:46.22 |
| | I think we might leak fz_drop_device() if pdf_run_glyph_func() throws. | 10:46.37 |
| | which it might do if the nested depth is > 10 | 10:46.55 |
| | also this one: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=blobdiff;f=source/fitz/stext-device.c;h=ac90814d865b03c21eae33bee96c2c78ffe12686;hp=c5073455f2bd15adf370bc8e441b849599f11221;hb=fa562f5ed6617b37636327356bd7653bdc39efa5;hpb=eb23fc80997bbb4409abe06a8392c0da4e445504 | 10:47.46 |
| | where I'm arguing that fz_resize_array() called by add_span_to_soup() might throw (OOM) and thus fz_stext_close_device() throws, which it may not. | 10:48.16 |
| | am I barking up the wrong tree here? | 10:48.39 |
| Robin_Watts | In the first one, I think you are right that we risk not dropping the device. | 10:48.56 |
| | I don't believe we guarantee that close won't throw. | 10:49.40 |
| | Hence anywhere that assumes that if | 10:49.55 |
| | Hence anywhere that assumes that is bad. | 10:50.00 |
| | We should be able to assme that drop won't throw, maybe. | 10:50.27 |
| sebras | Robin_Watts: right, then the mistake is in display_list_image_get_pixmap() which blindly calls fz_close_device() without a corresponding throw (and then simply drops the device). | 10:51.51 |
| | Robin_Watts: same in fz_prepare_t3_glyph(). | 10:52.43 |
| Robin_Watts | I'm just being distracted by some SOT stuff. | 10:53.15 |
| | tor8: You awake? | 10:53.18 |
| sebras | Robin_Watts: np. I need to go eat anyway. | 10:53.29 |
| tor8 | Robin_Watts: barely... | 10:53.35 |
| Robin_Watts | tor8: I had a crack at the fragment thing on friday. | 10:53.54 |
| | but it seems that my attempts to add a flow box to the appropriate place in the html structures are failing. | 10:54.15 |
| | When I dump the html after parsing, all my 'a' flow boxes are appearing at the end, and I can't see what I'm doing wrong. | 10:54.39 |
| | Could I ask you to take a quick look at the commits on robin/master please? It's probably something embarassingly simple. | 10:55.03 |
| | embarrassingly, even. | 10:55.15 |
| tor8 | will look | 10:55.32 |
| | you're adding the flow node without ensuring that you're adding to an inline box in the right context | 11:03.49 |
| | though that should not be a problem in practice, since you already run the DIS_INLINE block | 11:06.56 |
| Robin_Watts | tor8: When did you update the noto fonts? I remember seeing a commit just the other day. | 11:15.53 |
| tor8 | friday or thursday, from the latest noto git | 11:16.08 |
| Robin_Watts | There was an announcement referenced on slashdot this morning that they had just done a new release. | 11:16.09 |
| | thursday or friday sounds fine then. | 11:16.26 |
| tor8 | oh... let me pull and see if they updated any more | 11:16.27 |
| | they have not, the noto-fonts git had no updates since I pulled the fonts over for my commit the other day | 11:17.06 |
| Robin_Watts | cool. So just announcement lag then. | 11:18.36 |
| | Can I leave bug 697123 with you then? I hope what I have is close. | 11:19.09 |
| | sebras: Do you still have your patch for bug 697183 kicking around? | 11:19.58 |
| | sebras: Do you still have your patch for bug 697151 kicking around? (Sorry) | 11:20.11 |
| | I'm going to carry on looking at bug 697075 | 11:20.46 |
| tor8 | Robin_Watts: flow->box points to the 'inline' box which is only held for the css style properties | 11:38.11 |
| | inline boxes are never laid out, only block boxes and the automatically added 'flow' boxes | 11:38.30 |
| | which is why the y coord is never anything but 0 | 11:38.40 |
| Robin_Watts | tor8: Right, but that doesn't explain why when I dump all the html, all the 'a' things I add are listed at the very end of the doc. | 11:39.46 |
| tor8 | that's because of calling add_flow_anchor outside of the box where it needs to go | 11:40.13 |
| | I added a function generate_anchor modeled on generate_image which adds it to the proper box | 11:40.36 |
| Robin_Watts | tor8: Ah, fab. So it's working now? | 11:41.22 |
| tor8 | I've pushed a fix to tor/master which should work | 11:43.45 |
| | it works for the sample sherlock holmes epub at least | 11:44.15 |
| Robin_Watts | tor8: That does indeed solve it. | 11:58.33 |
| | Let me fixup those commits then. | 11:58.41 |
| | Thanks for that. | 11:58.49 |
| | tor8: Fixed version of those commits on robin/master then. | 12:09.17 |
| | Will just quickly run the cluster over them, but it fixes the bug. | 12:09.32 |
| | It does mean that we do a linear search of the doc to resolve every fragment in the outline. | 12:10.18 |
| | Possibly we could improve that massively by starting to search forwards from the last position we matched each time. | 12:10.44 |
| tor8 | or hoist the fragments into a smaller list of anchor points | 12:25.59 |
| | which would be a lot faster to linearly search | 12:26.08 |
| | put a list of pointers to the anchor flow nodes in the epub_chapter or fz_html root | 12:26.56 |
| | Robin_Watts: I've been meaning to split fz_html into fz_html and fz_html_box | 12:27.36 |
| | where fz_html would be the root and can hold some auxiliary stuff that shouldn't need to be in every html box | 12:27.55 |
| | and improves the naming of the data structures | 12:28.08 |
| | things like the pool allocator shouldn't need to be part of every box | 12:28.45 |
| | Robin_Watts: epub_update_link_dests sets node->dest.ld.gotor.page = ch->start twice | 13:00.41 |
| Robin_Watts | tor8: D'Oh. | 13:01.49 |
| tor8 | Robin_Watts: in the linked list simplification, I think I'd prefer the 'tail' variable to be named 'tailp' (since it's not a plain 'tail' pointer but a pointer to the next field) | 13:02.50 |
| Robin_Watts | tor8: ok. | 13:02.57 |
| | very hungarian. | 13:03.21 |
| tor8 | it's a pattern I've used elsewhere | 13:04.08 |
| | other than those two gripes, everything non-WIP on robin/master LGTM | 13:04.24 |
| Robin_Watts | Updated commits on robin/master. Just reclustering now. | 13:09.42 |
| | thanks. | 13:09.46 |
| tor8 | Robin_Watts: ah, I think I want to remove the 'remove needless parameter passing' commit if I am to do the fz_html/fz_html_box thing | 14:29.39 |
| Robin_Watts | ok. | 14:29.55 |
| | tor8: Sorry, Scott rang. | 14:39.16 |
| | Why? | 14:39.21 |
| | (Why would we need to remove that commit?) | 14:39.30 |
| | We pass both g and g->pool, which seems redundant. | 14:39.47 |
| tor8 | Robin_Watts: I'm just being confused. | 14:43.46 |
| | no need to remove it | 14:43.49 |
| | Robin_Watts: commit on tor/master | 14:46.06 |
| | saves a pointer per html node | 14:46.12 |
| Robin_Watts | Ok. will look now. | 14:47.19 |
| | There is 1 commit on robin/master too (together with the fixed ones from before). | 14:47.34 |
| | The fixed ones run clean. | 14:47.41 |
| | The new commit causes various progressions - you can see them in my bmpcmp area if you are so inclined. | 14:48.02 |
| tor8 | Robin_Watts: nice! | 14:49.36 |
| Robin_Watts | tor8: lgtm. | 14:55.48 |
| | I shall push then... | 14:56.15 |
| | 3 commits on robin/master | 17:54.57 |
| tor8 | Robin_Watts: LGTM | 18:31.44 |
| Robin_Watts | Ta. | 18:31.48 |
| | What do you think about bug 697094 ? | 18:32.03 |
| | I am inclined just to disable text form entry on linux. | 18:32.23 |
| | so things like calc.pdf should still work (though it isn't working for some reason) | 18:32.38 |
| tor8 | Yes. Until I get it working with the opengl-based viewer at least. | 18:33.21 |
| | calc.pdf is working for me (both mupdf-x11 and mupdf-gl) | 18:33.32 |
| Robin_Watts | tor8: Hmm.mupdf-x11 won't work with calc.pdf for me. | 18:34.46 |
| tor8 | Robin_Watts: what doesn't work? | 18:39.51 |
| Robin_Watts | The buttons click, but the numbers in the display don't change. | 18:40.08 |
| | Same thing works on windows. | 18:40.18 |
| tor8 | weird... | 18:40.21 |
| | I just did a clean build of robin/master and mupdf-x11 clicks and the display updates as it should | 18:40.47 |
| Robin_Watts | OK, a clean build has shaken something loose here. | 18:41.29 |
| | So, the patch on robin/master would be my suggested fix then. | 18:44.26 |
| tor8 | Robin_Watts: yeah, that one looks fine | 18:44.40 |
| Robin_Watts | Thanks. | 18:44.53 |
| Harley_ | Does ghostscript store a list of input file names stored some where so the file names can be read by a postscript file. | 19:57.24 |
| Robin_Watts | Harley_: Nope. | 19:59.05 |
| | sorry, gotta step away. | 19:59.16 |
| Harley_ | Can the Output file name be used in a postscript file | 20:04.57 |
| | I'll just keep digging through the source code looking around. | 20:16.54 |
| chris_x250 | Harley_: the output file name is stored in the dictionary returned by currentpagedevice under the key /OutputFile | 20:31.55 |
| Harley_ | Thanks chris | 20:39.37 |
| chris_x250 | Harley_: There is a non-standard way you can get the name of the *current* file being interpreted (as long as it's a normal file, and not a "special" one) | 20:41.16 |
| Harley_ | I was just wondering how ghostscript iterated through mutiple pdfs files on the command line. I want to have a customized postscript file do some processing on each file as the pdfwrite loops through each file. I was unsure how that would work. | 20:46.33 |
| chris_x250 | Ghostscript runs each PDF (or Postscript file) as it encounters it on the command line. | 20:47.22 |
| | It doesn't assemble an array of names, and iterate through the array, for example | 20:47.47 |
| | Harley_: So you want to change the output file for each input, too? | 20:51.21 |
| Harley_ | Not sure about the output file idea | 20:57.21 |
| chris_x250 | Harley_: if all you want to do is rattle through a list of PDF files, you can do it like this: http://pastebin.com/c2Usfvpc | 21:01.39 |
| Harley_ | I wanted to dump information about each pdf file as ghostscript iterates through each file while I was merging the files to make a source xml file for the newly created file. | 21:03.20 |
| chris_x250 | Alrighty........ | 21:05.26 |
| | Forward 1 day (to 2016/10/11)>>> | |
Log of #ghostscript at irc.freenode.net.