| | <<<Back 1 day (to 2015/02/10) | 20150211 |
| kens | ROFL henrys should be grateful he didn't live in FLorida: | 08:18.08 |
| | http://www.theregister.co.uk/2015/02/11/are_you_a_florida_resident_your_old_governor_might_have_just_pwnd_you/ | 08:18.08 |
| rsaarelm | Is this the place to talk to mupdf devs? | 09:17.36 |
| kens | Yes, though there may not be any here at present. Best thign to do is ask your question and it'll get ito the logs. Someone will answer when they come online | 09:18.06 |
| | For extermely simple stuff someone else may be able to help | 09:18.28 |
| rsaarelm | I use mupdf but I wanted the presentation mode advance page with mouse click functionality. Grabbed the source and patched it to do that when app is in presentation mode, seemed very straightforward at least given 10 minutes of experience with the codebase. Is there a place to submit the patch? | 09:19.49 |
| kens | Certainly, and they'll be delighted to look at it. Best thing is to submit it to our Bugzilla tracker at bugs.ghostscript.com | 09:20.30 |
| rsaarelm | Will do. | 09:20.37 |
| kens | You will need to do a contributer's agreement, it should be a click somewhere on the site. | 09:20.57 |
| | I think its available when you upload a patch, but I'm not absolutely certain | 09:21.21 |
| rsaarelm | Yeah. | 09:33.15 |
| | Ugh, pdf form, I've no idea how to actually fill these. Guess I can just screenshot and gimp it. | 09:33.33 |
| kens | Print it works too | 09:33.42 |
| | If you can scan the printeed/filled otu version | 09:34.01 |
| | Hmm, a type 1c font stream with a length of 54, that seems remarkably small...... | 09:35.56 |
| | chrisl I'm not certain this bug is fixable: http://bugs.ghostscript.com/show_bug.cgi?id=695819 | 09:40.32 |
| | The embedded fotn has an empty name index | 09:40.42 |
| | Its a dumb font anyway of course, because it only contains a /.notdef and what is probably a space glyph (it makes no marks) | 09:41.27 |
| | Oh yeah, teh Encoding has the glyph at index 32 | 09:41.47 |
| kens2 | OK looks like its something to do with teh font being 'deleted', I'll look at it more when I get back. I think this is going to be a 'wontfix'. | 09:47.20 |
| chrisl | kens2: don't we fall back to trying to load a font by name when the font stream fails? | 09:49.49 |
| kens2 | yes, but.... | 09:50.00 |
| | The font has no name :-) | 09:50.03 |
| | Its a subset prefix, and no actual font name | 09:50.11 |
| | SO we can't load a replacement, and the page processing aborts. | 09:50.29 |
| chrisl | Yes, but IIRC "/" is a valid name, so I'd expect we go to the default font | 09:50.44 |
| kens2 | Frankly, its a dumb PDF file which I strongly suspect has been produced by the customer's own in-house tool | 09:50.51 |
| | chrisl, well that doesn't 'appear' to happen.... | 09:51.00 |
| | After 'loading the font by name' we go to an error loading a content stream. | 09:51.23 |
| | Of course, if I set PDFSTOPONERROR I bail out after the first error, and so can't really see what its complaining baout | 09:51.45 |
| | Like I said, I'll look more closely when I get back | 09:51.55 |
| | Currently my thinking is this is a really dumb PDF file | 09:52.21 |
| chrisl | It is clearly broken, no doubt about that | 09:52.42 |
| kens2 | If it looks easy to have it fall back to the default font I'll do that, otherwise I'll just tell them its a really badly broken file and they should fix it. | 09:53.16 |
| | rsaarelm : thanks for quoting the SHA you used, I suspect the developers will appreciate that ! | 09:54.10 |
| rsaarelm | And inkscape-scribbled pdf form sent. | 09:55.08 |
| kens2 | Excellent, thanks very much. I'll have to leave the review and so on to others. | 09:55.30 |
| | And now I'm off for a bit. Patch Tuesday means my PC wants to reboot :-( | 09:55.49 |
| chrisl | rsaarelm: be warned, though, it may take a while - we're all decidedly busy just now | 09:56.01 |
| rsaarelm | No hurry, I can just use my local binary. | 09:58.06 |
| Robin_Watts | tor8: 2 of the commits on robin/master should now be good to go. | 11:18.29 |
| tor8 | Robin_Watts: image res and memento? LGTM | 11:20.09 |
| Robin_Watts | Thanks. | 11:20.18 |
| | The displaylist one is failing cluster testing at the moment :( | 11:20.27 |
| tor8 | Robin_Watts: though if you think the drop stuff is ready to go, it'd probably be easier for me to rebase your changes on top of that branch than the other way around | 11:20.59 |
| Robin_Watts | oops. I just pushed :( | 11:21.16 |
| | Let me look at the drop stff now. | 11:21.23 |
| tor8 | no worries, I'll sort it out | 11:21.24 |
| | there's one thing left I'm working on -- the pdf_csi and pdf_process mess of passing state around | 11:21.42 |
| | but that's all internal so invisible to users so far | 11:21.57 |
| | oh, and the javascript interpreters have internal contexts that should be rebound at every execution | 11:22.22 |
| Robin_Watts | ok, the reference counting paths thing... | 11:22.59 |
| | Suppose someone gives me a path, and I 'keep' it, and then I modify it. | 11:23.30 |
| tor8 | yeah. don't do that. | 11:23.40 |
| Robin_Watts | That affects the original path too. | 11:23.48 |
| tor8 | we only use paths in a create once/consume often pattern | 11:24.05 |
| Robin_Watts | We should at least assert that the ref count for a path is 1 in the path modificiation functions. | 11:24.32 |
| tor8 | yeah, that sounds reasonable | 11:24.44 |
| | and likewise for fz_text | 11:25.11 |
| chrisl | That prevents code having a read-only reference to the path | 11:25.27 |
| Robin_Watts | we don't have fz_text modificiation functions do we? | 11:25.48 |
| | chrisl: a) We have no concept of read only references currently. | 11:26.18 |
| | and b) if more than one person has a reference to a path, it's now exactly a read-only reference. | 11:26.43 |
| chrisl | Robin_Watts: So if, for some reason, I wanted to hold a reference to a path to monitor how segments were added to it, that would be impossible | 11:27.37 |
| Robin_Watts | It would. | 11:28.15 |
| | The alternative thing would be to have the path modification functions clone the path when shared paths are modified. That's what gs does. But it's overkill for our usage at the moment, and we can always add it later if required. | 11:45.19 |
| | I'm not sure I see why we need to ref count fz_document (except maybe for consistency) | 11:45.36 |
| | I fear we'll need locking if we ref count fz_path's. | 11:46.02 |
| | If we end up with a display list having a reference to a path, and someone else having a reference to the path (say in a cache somewhere), then the display list can be run in one thread, and the cache used in another. | 11:47.17 |
| tor8 | gah. bloody internet providers... | 11:54.01 |
| | non-providers more accurately | 11:54.14 |
| Robin_Watts | tor8: I burbled a bit while you were away. | 11:57.14 |
| | Other than what I burbled, the commits look OK. | 11:57.27 |
| | but the lack of locking on the reference counting (particularly for fz_path) bothers me. | 11:57.47 |
| tor8 | right. so add locks and asserts to not modify shared paths. | 11:57.52 |
| | we should add convenience macros fz_lock_pointer/unlock_pointer for the lock dance | 11:58.08 |
| | fz_document will need to be reference counted for when the fz_pages hold references to the owning document | 11:58.58 |
| | but I'm still not sure exactly what shape that should be | 11:59.06 |
| Robin_Watts | ah, yes. | 11:59.08 |
| tor8 | it may well be that the pdf_page specific subclass will hold a reference to the pdf_document instead | 11:59.20 |
| Robin_Watts | You realise binding pages to docs is exactly against the spirit of everything you've been doing in this commit? :) | 11:59.38 |
| tor8 | and that is currently done as embedded fz_document super but I'm thinking that maybe a void *userdata scheme might be more suitable | 11:59.55 |
| | Robin_Watts: yes. gotta balance good and evil ;) | 12:00.13 |
| Robin_Watts | void *userdata is bad. | 12:00.13 |
| | I'd rather see 'base' classes etc. | 12:00.32 |
| | nested structs as we discussed the other day. | 12:00.41 |
| tor8 | inheritance is bad. | 12:00.45 |
| | nested structs do have the benefit of being type castable | 12:00.57 |
| | but then you need to cast always | 12:01.16 |
| Robin_Watts | Yes. | 12:01.20 |
| | cast is prefereable to a void *userdata pointer. | 12:01.38 |
| tor8 | fz_device could be made castable rather than using userdata pointers | 12:01.47 |
| Robin_Watts | cos you're effectively casting with that too. | 12:01.47 |
| tor8 | it would make device setup simpler I expect | 12:02.00 |
| | yeah, except with help of the compiler. still the same dangers involved though. | 12:02.14 |
| Robin_Watts | I prefer explicit to implicit. | 12:02.31 |
| tor8 | fair enough | 12:03.02 |
| Robin_Watts | runs for a bit. | 12:03.46 |
| tor8 | so fix the pdf_csi embedded context, make fz_device a nested struct, and then the counter-balancing evil embed-a-doc-in-fz_page | 12:03.52 |
| | the alternative is to keep it as is, but then the FFI bindings to java and javascript will be less idiomatic | 12:04.25 |
| Robin_Watts | tor8: Yeah. | 12:04.31 |
| tor8 | which would be a shame, but mirror the way the C apis work more closely | 12:04.47 |
| Robin_Watts | The JNI stuff has magic in to bind the pages and docs together. | 12:04.52 |
| tor8 | but then you feel like you're working in C but in a different language | 12:04.57 |
| Robin_Watts | would be nicer to avoid that. | 12:04.57 |
| tor8 | yeah, that's my thinking as well | 12:05.03 |
| | especially since it's required to always pass the same doc, might as well embed it | 12:05.18 |
| | if necessary | 12:05.23 |
| Robin_Watts | indeed. | 12:05.27 |
| tor8 | I guess we could let the subclasses deal with that | 12:05.30 |
| Robin_Watts | You can't sensibly 'rebind' a page and adoc. | 12:05.36 |
| tor8 | cbz would just stick a fz_image in the page and not worry | 12:05.39 |
| flex | hi is it possible to export and import annotations in the mupdf library? | 14:04.26 |
| kens | You can add some limited kinds of annotations to a PDF file, I don't know what you mean by export and import. | 14:05.00 |
| flex | so i dont want to burn the annotations into the pdf i want to export them and xml? | 14:05.31 |
| | and load the annotations from xml? | 14:05.42 |
| kens | Still baffled. Annotations are a component of a PDF file, not clear to me how you can have annotations without having them in a PDF file. | 14:06.09 |
| | If you want to find out what annotations are in a PDF file I'm reasonably sure you can do that. | 14:06.39 |
| flex | there are libraries available that allow the export of annotations on the pdf as xml files so there is no need to save multiple versions of the same pdf file by saving/loading the annotations separate to the actual pdf | 14:08.34 |
| kens | OK but then these are no longer annotations. | 14:09.05 |
| flex | so in the xml files you would have the descriptions of all the annotations for a particular pdf | 14:09.06 |
| kens | A PDF consumer would tehn not be able to render the annotations. | 14:09.28 |
| flex | they will be once they are reapplied to the pdf? | 14:09.34 |
| kens | Yes, you could potentially do that. | 14:09.45 |
| | No MuPDF doesn't do it. | 14:09.51 |
| flex | its there a way to get all the current annotations on the documnet? | 14:10.26 |
| kens | I'm not really the right person to answer that. Certainly you can walk the tree and recover teh annotations for each page, and I'm pretty certain you can interrogate each of the annotations. You can't do it 'globally' because annotations are applied on a per-page basis | 14:11.17 |
| | paulgardiner : You seem like you would know more about this than me. | 14:12.46 |
| paulgardiner | MuPDF provides no specific way to do that, but it does provide general ways to access the structure of a document, so you could access the annots array of each page object | 14:17.00 |
| | Importing would probably be the hard part because as well as filling in the annot dictionary in the PDF file, for each annotation, you also need to generate appearance streams. We have code that does that for some annotation types, but not all | 14:18.49 |
| kens | You don't *have* to generate an appearance stream, but if you omit it, PDF consumers may display nothing. | 14:19.29 |
| flex | ok so for each page if i export out each annotation into some form of xml i should be able to reload it, i will look into this | 14:21.40 |
| kens | You will have to write the reloading code as well don't forget. | 14:21.58 |
| chrisl | kens: I had a quick look at that broken font PDF file - it should be possible to have the code fall back to loading by name if the font stream fails..... | 14:32.43 |
| kens | It should already work I believe, teh problem seems to be that we pass the wrong object to run-fonttypeprocs | 14:33.10 |
| | We're passing it a -file- and it exepcts (I htink) a -dict- | 14:33.36 |
| chrisl | Oh, okay. Longer term, we *could* make the CFF parser more tolerant | 14:33.58 |
| kens | Well, it looks to me like our CFF parser is arguably correct. A CFF font with no names has no fonts.... | 14:34.28 |
| | If you've got a minute, can you look at /resourcefont in pdf_font.ps ? It looks broken to me.... | 14:34.50 |
| chrisl | OKay, I've got it in front of me..... | 14:36.04 |
| kens | OK so there's a l;ine which looks for /FontDescriptor | 14:36.26 |
| | about line 2104 | 14:36.32 |
| | YMMV I've edited my file | 14:36.41 |
| chrisl | dup dup /FontDescriptor knownoget | 14:36.49 |
| kens | Under that it does some stuff looking for a Subtype | 14:36.56 |
| | and ends up pushing eitehr /CIDFontObject or /FontObject | 14:37.16 |
| | WHich it never seems to remove from the stack, and doesn't seem to use..... | 14:37.30 |
| | There are no other references to FontObject in either the .ps or .c files. | 14:37.46 |
| | So I'mpuzzled as to what its doing there.... | 14:38.02 |
| | Also, rather bizarrely, the 2 index 1 index .knownoget seems to me to be checking for the existence in a dictionary of another dictionary | 14:39.59 |
| chrisl | The /(CID)FontObject name is used | 14:41.06 |
| kens | OK I didn't grep that one. | 14:41.21 |
| | How is it used ? | 14:41.27 |
| | My assumption was that these would be defined in the font resource if we had already loaded the font, so we could just use the existing object. | 14:41.49 |
| chrisl | In my pdf_font.ps line 2172: "put % Save pointer to the font." | 14:41.54 |
| kens | Interesting, that's in the error condition. | 14:42.21 |
| | We only get to there if we failed to load the font (we have a null on the stack) | 14:42.43 |
| chrisl | No, it's after that | 14:42.50 |
| kens | Oh sorry, so it is, my file is confused there, I have ltos of debugging in it | 14:43.07 |
| chrisl | I'm not at all clear what the *purpose* of storing the font in there is, but we do..... | 14:43.41 |
| kens | I htink it stops us having to reload it from the FOntFile | 14:43.58 |
| | Once we've made a font object we store it in the font resource, so next time we use the resource we already have the font ready to go | 14:44.20 |
| chrisl | But as you said, we never reference that key again, so..... | 14:44.31 |
| kens | Yeah, but I think that';s the error. | 14:44.46 |
| | Where we do 2 index 1 index .knownoget, that's always going to fail because we don';t use the key we loaded, but I htink we *should* be using the key | 14:45.22 |
| chrisl | Ah, yeh, I see..... | 14:45.23 |
| kens | Not that this is the problem I'm looking at :-) | 14:46.21 |
| chrisl | So, we are probably rerunning font streams far more often than necessary..... | 14:46.50 |
| kens | But it 'looks like' that's supposed to short-circuit the font loading for fonts that we have already loaded, so its a performance optimisation, and it looks to me like its broken | 14:46.54 |
| | chrisl, yes, that's the first problem I see there. | 14:47.15 |
| | I think the '2 index 1 index' maybe should be '1 index 0 index' but I'm not certain. Not sure exactly what's in the dicts at that point. | 14:47.49 |
| mvrhel_laptop | good morning | 14:48.08 |
| kens | Morning mvrhel_laptop | 14:48.14 |
| | Anyway, the upshot is that when we run pdfformaterror and then run-fonttypeproc, the top entry on the stack is not a 'res' its a -file- andthat's why it fails to load the default font. | 14:49.04 |
| | Anyway. thanks for talking it over, I'll go back to picking the code apart for a while, I might ask you for another opinion later :-) | 14:49.29 |
| chrisl | kens: possibly when you fathom what's going on you could fix the stack comment "% font-res obj" in there - I'm not at all sure it's right, and "obj" isn't a very helpful description! | 14:51.24 |
| kens | No, I htink the comment is wrong (well actually its *defintiely* wrong currently) | 14:51.49 |
| | And yes, the commetns are less than helpful, I suspect these are Alex comments | 14:52.02 |
| | Like I said, I'll carry on figuring out what's being loaded | 14:52.20 |
| | This may take a while.... | 14:52.30 |
| chrisl | The time saving in fixing that optimisation could, potentially, be significant | 14:53.07 |
| kens | I thought that too :-) | 14:53.25 |
| | Reloading fonts from file multiple times could be quite lengthy | 14:53.45 |
| | I'll hold off on doing anything just yet though, I need to understand what's going on in there more generally, but I'm happy you agree wiht me tabout what it probably for, and that its currently broken :-) | 14:54.37 |
| kens | fetches a fresh ionfusion of programmer fuel | 14:55.04 |
| chrisl | "ionfusion"? Sounds like the power source for a superluminal drive system :-) | 14:56.17 |
| kens | Could ask ROstam about it maybe >:) | 15:02.12 |
| chrisl | I'm sure he's built one single-handed..... or will claim to have, anyway | 15:03.18 |
| kens | Have you seen the GG share price recently ? Up over 2 Euros | 15:04.25 |
| chrisl | I haven't been watching it, no.... I wonder what they've got cooking for that to happen | 15:05.13 |
| kens | NO idea, there's nothing in their news | 15:05.31 |
| | Looks to me like its just the usual rising tide | 15:06.28 |
| | Well, that's progress, got it substituting Helvetica for YXKJJA+ before it then fails again :-) | 15:35.42 |
| | OK looks like ReadType1C is leaving the stack disturbed when it fails | 15:39.26 |
| henrys | trip is on for mid-march after the meeting. | 15:53.42 |
| rayjj | mvrhel_laptop: I think the problem with pattern-clist is that we don't push and pop an isolated transparency group for the filling. If it's possible to get the right answer by "rendering directly into the "primary buffer" (as the comment on line 2828 of gdevp14.c states), I it will require different painting blending than what we have | 16:46.09 |
| | mvrhel_laptop: if it's even possible | 16:46.51 |
| | mvrhel_laptop: so I'm going to add in a push/pop around the pattern-clist case as well. The key is to limit the rect to the clist band size so that we don't try to operate with transparency buffers that are the size of the pattern rect (which is the whole point of having a pattern-clist). | 16:51.04 |
| | mvrhel_laptop: now that I have given up on trying the get the painting directly into the primary buffer working when playing back the pattern-clist, I should be able to get something for you to have a look at today. | 16:52.16 |
| | mvrhel_laptop: if you are willing/able to take a break from other fun stuff (e.g. SOT) | 16:53.09 |
| mvrhel_laptop | rayjj: sorry stepped out for a sec | 17:00.55 |
| | rayjj: sounds like you made some nice progress | 17:01.28 |
| rayjj | mvrhel_laptop: taking FOREVER. I've reduced the file and file size down to something I can debug / step through. Then looking for some error in the math (if there is one, I can't see it) | 17:02.57 |
| | mvrhel_laptop: but the numbers are so different when blending on top of something that's already in the buffer compared to painting into an isolated group, then blending, that I'm mostly surprised that it is as close as it is | 17:05.21 |
| mvrhel_laptop | right | 17:06.04 |
| rayjj | mvrhel_laptop: which makes me suspect there might be a way to do it, but pushing a group is MUCH easier than trying to puzzle out the math | 17:06.10 |
| mvrhel_laptop | hmm looks like I need to rewrite the xps printing section for gsview. The approach that I did is actually not the preferred method. They have too any APIs for doing this. Looks like the most recent one handles the oxps content directly. Have to write it in c++ but that will not be end of the world | 17:30.14 |
| | Forward 1 day (to 2015/02/12)>>> | |
IRC Logs