| | <<<Back 1 day (to 2016/07/18) | 20160719 |
| sebras | fredross-perry: I just pushed a complete fix for yesterdays issues to golden | 14:10.27 |
| fredross-perry | swell, thanks. | 14:10.51 |
| | sebras - looks good so far. | 14:46.23 |
| sebras | fredross-perry: excellent. | 14:48.13 |
| fredross-perry | sebras - do you have a file with links that I can test with? | 15:12.09 |
| sebras | fredross-perry: http://www.adobe.com/content/dam/Adobe/en/.../pdfs/pdf_reference_1-7.pdf has links on page 5 I believe | 15:13.12 |
| | fredross-perry: make that http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf | 15:14.04 |
| fredross-perry | thanks | 15:16.55 |
| | sebras - that file I sent you yesterday (building.pdf) has a link on the first page, that's not found. | 15:34.34 |
| sebras | fredross-perry: let me have a look. | 15:36.03 |
| | fredross-perry: yes, but it has no link annotation, so mupdf treats it as nicely underlined, blue colored text. :) | 15:40.12 |
| | fredross-perry: evince and xpdf also do not treat it as a link. | 15:41.44 |
| Robin_Watts | acrobat 'magically' spots http://blah things as links. | 15:43.48 |
| sebras | Robin_Watts: is that something we'd like to support? | 15:46.17 |
| Robin_Watts | sebras: If we do, it should be done in the app, not in the core, IMAO. | 15:46.57 |
| sebras | Robin_Watts: if so I'm guessing we'd like that to be part of the mupdf lib proper to the benefit of all platforms. | 15:46.59 |
| | Robin_Watts: ok... that means we come from different viewpoints. :) then there should be some app layer where this magic goes? | 15:47.52 |
| | Robin_Watts: what about file:// ? or ftp:// or sftp:// ? | 15:48.13 |
| Robin_Watts | sebras: I have no idea. | 15:48.34 |
| sebras | basically everything [a-z]*://[^whitespace]\+ I'm guiessing. | 15:48.36 |
| Robin_Watts | needs to crawl under a rock for a bit and concentrate on mvrhel's problem. Repeated context switches cause me to drop everything in cache each time. | 15:49.31 |
| fredross-perry | Interestingly, Preview (osx) allows me to click on it as though it were a link. | 16:05.01 |
| sebras | fredross-perry: yes, I had a check in pdfium which recognizes the link, and they indeed skip any Link annotations and instead go looking for http:// https:// and www. in the page text. | 16:41.34 |
| | fredross-perry: I'm trying to determine if the same is true for pdf.js | 16:41.58 |
| fredross-perry | Probably the same for Preview. | 16:42.01 |
| | Might be good to synthesize a link annotation, depending on how we use them. Maybe add a Link member to indicate that it's synthetic. And don't save them. | 16:43.23 |
| sebras | fredross-perry: something link that. the question is if this is to be done by the app or by the library. if we want to share the same with iOS I'm guessing it will have to be done in libmupdf proper. | 16:47.22 |
| fredross-perry | I think so. | 16:48.30 |
| sebras | fredross-perry: we discussed while you were away and there were different opinions on where to implement this. | 16:49.27 |
| fredross-perry | can you meet me over at #artifex? | 16:49.48 |
| sebras | fredross-perry: I've put it in my local TODO at least. | 16:49.51 |
| fredross-perry | sebras: (for the logs) I think that Outline.java could use an indiction of what "level" in the hierarchy the item is at, so in the UI we can indent. | 18:36.39 |
| sebras | fredross-perry: I'm guessing that you saw how I did the indentation in Outline.toString() for child elements in Outline.down[] but decided that this was not useful..? just checking.:) | 19:03.43 |
| | fredross-perry: conceivably we could decide to add a public int level member and flatten the entire hierarchy (i.e. removing Outline.down[] entirely). | 19:05.07 |
| | fredross-perry: but the underlying data structure doesn't look like that so in iOS this would need to be done manually. | 19:05.41 |
| | fredross-perry: or we'd need to change the underlying data structure too of course. | 19:06.00 |
| Robin_Watts | fredross-perry: You get the depth by it's position in the tree, right? | 20:46.04 |
| fredross-perry | Right. I think the recursize thing that builds the final array can just keep track of the "level", and stick that into new member. | 20:46.57 |
| | I cannot type well, as you see. "recursive". | 20:47.37 |
| Robin_Watts | fredross-perry: My point is, do we want to do that? Or do we want to just let the callers keep track? | 20:48.00 |
| fredross-perry | Caller can't (I think) keep track, 'cause loadOutline just builds one flat Array. | 20:48.40 |
| Robin_Watts | fredross-perry: It does?! | 20:48.50 |
| | I thought it built an array of Outlines, and some had child arrays.... | 20:49.16 |
| | I have to step away... sorry. I was expecting a tree like structure, not a flat structure. | 20:49.45 |
| fredross-perry | Oh wait, NM. I see my mistake. Sorry to have bothered. | 20:50.06 |
| | I did not spot "public Outline down[]" inside Outline. | 20:50.32 |
| | robin - working now thanks | 21:04.15 |
| boris | hi | 21:15.09 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 21:15.09 |
| boris | I have a fix for ghostpdl | 21:16.14 |
| | how can I open a pull request for it? | 21:16.21 |
| | I had an issue with building without contrib in out-of-tree mode | 21:26.01 |
| | patch https://gist.github.com/0f1e6242450c139d9a3f771260acb4eb fixes the problem | 21:26.17 |
| | goodbye | 21:26.34 |
| HenryStiles | I guess chrisl will see that patch in the logs | 21:56.44 |
| | Forward 1 day (to 2016/07/20)>>> | |
IRC Logs