| | <<<Back 1 day (to 2013/02/25) | 2013/02/26 |
| marcosw | I messed up ~1/2 of the cluster nodes, but they'll recover on their own in a couple of hours. | 00:02.28 |
| Srini | Hi all here | 10:43.49 |
| | I am trying to extract fonts from a pdf file... pdfinfo shows the fonts tobe cid identity-h fonts... extractFonts.ps failed to extract the fonts... trying to build mupdf on ubuntu... it is not compiling and installing pdfextract ... can anyone help me out please! | 10:45.17 |
| | Is there a sure way of extracting fonts from pdf? | 10:45.44 |
| Robin_Watts | Srini: bulding from source or from a package manager? | 10:46.49 |
| Srini | Robin_Watts, I build mupdf from sources | 10:53.50 |
| | git ghostscript | 10:53.55 |
| | it did not build pdfextract | 10:54.09 |
| | is there a patch? | 10:54.18 |
| Robin_Watts | make all ? | 10:54.49 |
| Srini | I tried apt-get install mupdf-tools, even then it id not install the pdfextract :( | 10:54.50 |
| | Robin_Watts, yes make all | 10:55.04 |
| Robin_Watts | OH, well, now you get mutool, right? | 10:55.06 |
| | "mutool extract" is the new equivalent to pdfextract | 10:55.23 |
| Srini | Robin_Watts, it did not create a mutool also! | 10:55.47 |
| Robin_Watts | Did you "make all" ? | 10:56.02 |
| Srini | Yes I did! | 10:56.16 |
| femfum | Hi, someone could advise me on how to share PostScript code, via web place (like GitHub or PasteBin), with code-highlighting? (usually we work with VIM editor and TOhtml method) â¦thanks! | 10:56.30 |
| Robin_Watts | make all should have left mutool in build/debug | 10:57.37 |
| Srini | Robin_Watts, you are right it is! | 10:58.00 |
| Robin_Watts | so maybe you want make all build=release | 10:58.11 |
| Srini | Robin_Watts, and make install followed by that? | 10:59.40 |
| Robin_Watts | make install build=release | 10:59.55 |
| Srini | Robin_Watts, That was help! | 11:01.10 |
| | Thanks! | 11:01.16 |
| Robin_Watts | np | 11:01.20 |
| Srini | Robin_Watts, gs can convert pdf to html? | 11:05.53 |
| | Sorry if I am singling out you Robin_Watts ! | 11:06.34 |
| chrisl | Srini: gs cannot convert pdf to html, no | 11:07.07 |
| Srini | chrisl, Thanks! | 11:07.27 |
| chrisl | np | 11:07.33 |
| Robin_Watts | Time for us to sue LG? | 11:09.25 |
| | http://www.theregister.co.uk/2013/02/25/lg_acquires_webos/ | 11:09.31 |
| chrisl | I wonder why they would want it...... | 11:11.14 |
| Robin_Watts | For Smart TVs | 11:11.31 |
| chrisl | Yeh, but why start with WebOS | 11:11.56 |
| Robin_Watts | Srini: No, but mupdf can, in some sort of way. | 11:14.09 |
| | mudraw -tt in.pdf > out.html | 11:14.21 |
| femfum | sorry if my question about PS syntax-highlighting seems to have no sense, but the main web sites to share code, don't have the PostScript language available | 11:16.33 |
| Srini | Robin_Watts, Formatting like bold italic subscript superscript is not possible that way? it is plan text? | 11:17.45 |
| chrisl | femfum: I don't know any pastebin type site with PS syntax highlighting - if you find one, let us know! | 11:17.47 |
| chrisl | has to head out for a while..... | 11:18.51 |
| femfum | chris1_away: yes, of course â¦we ask why :-) | 11:20.08 |
| Robin_Watts | Srini: Information is put into the css. | 11:21.37 |
| | femfum: Cos in order to syntax highlight you have to have some structure, and ps is practically structure free. | 11:22.17 |
| Srini | Robin_Watts, Yes! | 11:24.01 |
| | Thanks! | 11:24.04 |
| Robin_Watts | you're welcome. | 11:24.15 |
| femfum | Robin_Watts: I agree, but, for example, visually is better to follow a large program with the VIM PS syntax on enabled | 11:29.00 |
| tor8 | Robin_Watts: hm, I wonder why "mutool" has pulled in all the cmap and font resources... | 12:14.46 |
| | right, somewhere in the 'forms' branch merge back in september... | 12:31.20 |
| paulgardiner | Robin_Watts, tor8: a few commits on paulg/master, if you have a moment | 13:02.59 |
| tor8 | paulgardiner: can I pick your brain about some pdf_forms things? | 13:04.31 |
| paulgardiner | sure | 13:04.40 |
| tor8 | pdf_form.c has a function measure_text which calls pdf_run_glyph | 13:04.50 |
| | doing that pulls in the interpreter when linking, and the interpreter pulls in the big font data blobs | 13:05.25 |
| | now, I have no problem with forms requiring the interpreter | 13:05.43 |
| | but I need to understand why mutool.c pulls in pdf_form.c | 13:06.05 |
| | (as a bit of history, we have pdf_new_document_no_run just to let mutool tools that don't need the interpreter avoid pulling in the huge data blobs) | 13:06.47 |
| paulgardiner | what if you remove pdf_form.c from the build? Do the unresolved functions point at any reason? | 13:07.42 |
| sebras | tor8: update doc/example.c with regards to -lpng. I might do it, but it will take some time... | 13:08.24 |
| tor8 | paulgardiner: /facepalm should've tried that! | 13:08.40 |
| | sebras: I'm just curious why you put it there. I can take it out easily enough. | 13:08.55 |
| | we've *never* ever used libpng in mupdf | 13:09.02 |
| | paulgardiner: so, fz_free_widget and pdf_update_appearance | 13:09.21 |
| sebras | tor8: I think this was before the git submodule things... | 13:09.49 |
| tor8 | sebras: we've still never used libpng... | 13:10.19 |
| paulgardiner | tor8: Ah. Possibly pdf_update_appearance should be in pdf_annot.c | 13:10.22 |
| | ... but I'm unsure what else it would drag in. | 13:10.40 |
| tor8 | fz_free_widget should be in doc_interactive.c shouldn't it? | 13:11.29 |
| paulgardiner | Hmmm. Come to think of it pdf_update_appearance does need to measure test | 13:11.32 |
| | tor8: Yes, I'd have thought so | 13:11.57 |
| sebras | tor8: d'oh! you're right of course! *puts head in a brown paper bag* | 13:12.28 |
| tor8 | paulgardiner: update_annot is a bigger headache | 13:12.32 |
| | paulgardiner: since I think load_page may be called by some tools without wanting to actually run the page contents | 13:13.17 |
| | paulgardiner: hm. it may help looking at the current stuff instead of the merge that introduced pulling in the data blobs... | 13:14.55 |
| | so doc_interactive needs a lot of pdf functions from pdf_forms, but that's probably okay (though the dependency going that way is a bit...odd) | 13:15.43 |
| | there's still update_appearance and pdf_field_type being called in pdf_annot.c | 13:15.59 |
| | but now there's more than just measuring text that pulls in the interpreter | 13:16.51 |
| paulgardiner | I'm pretty sure pdf_field_type could move to pdf_annot.c (or a separate file) without dragging too much with it. | 13:17.46 |
| | With update_appearance, I'm unsure as to why I arranged for it to be called on loading the annotations. | 13:18.29 |
| tor8 | paulgardiner: I've been trying to keep the mupdf code in "layers" where the bottom layer that deals with objects, streams, filters and the xref etc doesn't depend on the content stream interpreter or device interface | 13:19.50 |
| | of course, it's not always easy! | 13:19.57 |
| | not when pdf_xref is the dumping ground for all manners of caches etc | 13:20.08 |
| | so maybe we should just give up that thought and not worry too much | 13:20.19 |
| | still, if it can be arranged to not have hard linked dependencies, I consider it a big win in terms of code separation and clarity | 13:20.52 |
| | and if that requires hacks like filling in function pointers to avoid hard linking, then that's a clear reminder of where the abstraction falls down | 13:21.22 |
| paulgardiner | We have this strange split between fz_annot and fz_widget, which are under-the-hood the same thing, but obtained in different ways. | 13:25.03 |
| tor8 | paulgardiner: there's also the question whether it's worth keeping them in the fz namespace | 13:25.33 |
| | nothing but pdf will be using annots and widgets, as far as I can tell | 13:25.53 |
| paulgardiner | That was the abstraction that fz_interactive was supposed to help with. | 13:26.26 |
| tor8 | yes, but re-evaluating decisions occasionally is not to be frowned on :) | 13:26.58 |
| | if it's working out, then great! if it's just making your work more troublesome, ... | 13:27.18 |
| paulgardiner | I totally agree. | 13:27.20 |
| tor8 | there's now a set of annotation types in fitz.h which probably only makes sense for PDF | 13:28.04 |
| | the fitz doc_interactive.c forwarding layer is simple enough I guess that it doesn't pose a big headache | 13:28.46 |
| | but API decisions like that makes one wonder where the abstraction starts leaking too much | 13:29.04 |
| paulgardiner | Yes, I see what you mean about the annotation types | 13:30.13 |
| | I'd imagined the abstraction left open the possibility to deal with another file type one day that had some of the interactive features of pdf, but as you say having types that are pdf specific blows that away | 13:31.26 |
| tor8 | yup. that's what I meant. | 13:31.46 |
| paulgardiner | Also, at the time, the only other option seemed to be to add lots of new indirected doc functions, but I guess just testing if a doc is a pdf and then casting is an alterntive. | 13:32.34 |
| tor8 | yeah. maybe a pdf_document *pdf_cast_document(fz_document *doc) and that returns NULL if it's not a PDF | 13:33.16 |
| paulgardiner | Ah yes | 13:33.24 |
| Robin_Watts | Do we not have a meta function? | 13:33.55 |
| tor8 | Robin_Watts: I hate the meta function... | 13:34.10 |
| paulgardiner | Even if we do, pdf_cast_document is nice | 13:34.22 |
| tor8 | but yes, the meta function should be able to return the document type | 13:34.37 |
| paulgardiner | Then drop all the fz_interactive stuff | 13:34.47 |
| Robin_Watts | We use the meta function to find out if it's a pdf document, and if so, we can cast. | 13:35.03 |
| | and we can implement pdf_cast_document using that. | 13:35.11 |
| paulgardiner | I don't think any of this will help unlink update_appearance... other than perhaps make the code look simpler so we can understand what's going on better | 13:35.24 |
| Robin_Watts | so the users get a nice function, and we don't bloat the document interface. | 13:35.29 |
| tor8 | making the code simpler is worthwhile in any case! | 13:35.45 |
| paulgardiner | Robin_Watts: yeah. sounds good | 13:35.53 |
| | tor8: yes | 13:35.59 |
| | I could make that change when I've finished sorting out why I'm getting opaque highlights. | 13:37.40 |
| tor8 | paulgardiner: removing both doc_interactive and pdf_form we get link erros from pdf_load_annots and pdf_update_annot to update_appearance and field_type | 13:38.01 |
| | paulgardiner: maybe we can split pdf_annot.c into non-interactive and interactive halves | 13:38.48 |
| | and your mixing of widget and annot when they're both the same pdf structures under the hood, I'll leave that choice up to you | 13:39.17 |
| paulgardiner | The problem is avoinding updating appearance streams on the load call | 13:39.21 |
| tor8 | paulgardiner: that's where we synthesize appearance streams if they're missing? | 13:40.29 |
| paulgardiner | Yes, and update ones that have been left dirty by their values being altered without their appearance streams | 13:41.10 |
| Robin_Watts | In the absence of forms, the only time we need to update annots are when they haven't had appearance streams to start with, yes? | 13:42.02 |
| paulgardiner | Hmmm and somewhere we deal with the possible change due to the mouse being down over a widget | 13:42.11 |
| tor8 | right. that makes sense to do when loading an annot. so we should probably not load annots in mutool tools. | 13:42.21 |
| paulgardiner | Robin_Watts: well, we were getting away without doing that at all before form support was added. | 13:42.40 |
| | ... but maybe it is desireable in any case | 13:42.53 |
| Robin_Watts | What tor8 says is simpler, I think. | 13:42.59 |
| | If we can avoid loading annots in mutool tools, we should be OK. | 13:43.13 |
| paulgardiner | With an ifdef? | 13:43.52 |
| Robin_Watts | No, we shuffle all the load_annots stuff into a different partitioning of the files. | 13:44.22 |
| tor8 | paulgardiner: by not calling pdf_page | 13:44.25 |
| | and by shuffling functions around in files | 13:44.41 |
| paulgardiner | Ah right.... ish | 13:45.27 |
| | not calling pdf_page? Not getting that bit | 13:45.58 |
| tor8 | paulgardiner: nvm, it doesn't matter | 13:50.15 |
| | I've nailed the two functions that pull in the interpreter in pdf_form.c | 13:50.24 |
| | paulgardiner: (I meant pdf_load_page) | 13:50.38 |
| paulgardiner | right | 13:50.57 |
| tor8 | pdf_measure_text, pdf_text_stride and pdf_load_font/drop_font are the entry points we need to isolate | 13:51.04 |
| | and they're all used by update_text_appearance, called by pdf_update_appearance | 13:51.53 |
| | so we're out of luck there! | 13:51.57 |
| paulgardiner | Yep. It's definitely update_appearance that is the problem | 13:52.22 |
| Robin_Watts | To return to what I was saying before... | 13:52.32 |
| | If update_appearance is only really needed if we have forms... | 13:52.55 |
| | and forms is only really needed if we are running the interpreter... | 13:53.12 |
| paulgardiner | Really in update_appearance we should fill in all missing annoations. | 13:53.52 |
| Robin_Watts | then can we isolate update_appearance via a function pointer that is set/not set in pdf_open_document/pdf_open_document_no_run | 13:54.12 |
| paulgardiner | The need to generate appearance streams isn't forms specific, but still perhaps if you don't intend to run them, there is no point to generating them | 13:57.08 |
| Robin_Watts | Seems fair to me. | 13:57.44 |
| paulgardiner | Alternatively there may be a simple way to avoid calling update_appearance from load_annots, and instead ensuring that it is called before running them | 13:59.16 |
| Robin_Watts | A 'needs_update' flag stored somewhere? | 13:59.50 |
| paulgardiner | The need updating in two cases: they don't exist or the widget object has a Dirty flag set | 14:00.45 |
| Robin_Watts | both of which you can spot when running them? So no flag may be required? | 14:01.23 |
| paulgardiner | Yes. The problem though, is there may be code that assumes they exist and will fall over if they don't | 14:01.55 |
| | though such code would be better fixed | 14:02.16 |
| Robin_Watts | right, but we could implement an 'ensure_updated' call, and insert that in various places ? | 14:02.32 |
| paulgardiner | update_appearance is a ensure call | 14:02.56 |
| | It does nothing unless one of those two conditions hold | 14:03.15 |
| Robin_Watts | ok, so basically it's a matter of moving the pdf_update_appearance call from load_annots to 'just in time' before stuff is used. | 14:03.33 |
| paulgardiner | I'd like to think so. :-) | 14:04.01 |
| | Perhaps just move it to pdf_run_annot. | 14:05.00 |
| tor8 | now is when you want a wall-sized printout of a graph of all object and function dependencies | 14:05.09 |
| paulgardiner | I'd have thought moving it from load to run had some chance of solving the link problem. | 14:08.09 |
| | Other than pdf_widget_type | 14:08.33 |
| | There's some chance it would mess up partial update because that keys on changes to the appearance streams. | 14:13.02 |
| tor8 | paulgardiner: okay, I think splitting pdf_annot.c into interactive/non-interactive functions and moving the update_appearance to running time should solve the dependency | 14:13.03 |
| | there's a lot of dependencies on pdf_annot.c from various files | 14:13.21 |
| | pdf_xref has the annot enumerator | 14:13.29 |
| | but if we ditch the fz_interactive, I think that enumerator can be move away from the function pointer table in pdf_xref | 14:13.51 |
| paulgardiner | I think we can do both those things independently. | 14:15.26 |
| | It's actually fz_interactive that kept the widget enumerator out of the xref | 14:15.48 |
| | Does this need doing for the release? | 14:16.50 |
| tor8 | it would be good if we could (since it blows up mutool from 1.2M to 8.1M, but I won't force the issue | 14:19.27 |
| paulgardiner | The blowing up of mutool can be solved without removing fz_interactive fz_annot fz_widget etc. | 14:20.16 |
| | I could have a go at moving pdf_widget_type into pdf_annot.c and calling update_appearance from run rather than load... oh hang on... we'd then need run_annot to be moved out of pdf_annot.c | 14:22.31 |
| | I could also have a go at getting rid of fz_interactive et al, of course. | 14:25.37 |
| | But it would be really nice to get my current commits in before the latter. :-) | 14:28.46 |
| tor8 | paulgardiner: yes. I've looked through the non-android ones and they look fine (given the subsequent rejigging of interactive and annot/widget back into mupdf.h we've been talking about) | 14:31.50 |
| | question is what to do about the release, do it now with the bloated mutool exe or wait? | 14:32.26 |
| paulgardiner | The changes just for avoiding the bloat might be few, although it looks like we do need to split pdf_annot.c, but between run and load, rather than interactive and noninteractive. | 14:34.56 |
| | We have a meeting later. henrys is good at making decisions. | 14:36.48 |
| tor8 | paulgardiner: run would be part of interactive | 14:39.13 |
| | *could | 14:39.25 |
| paulgardiner | oh ok. that makes sense | 14:39.27 |
| tor8 | which leaves very little non-interactive. feel free to come up with some other organisation between annot.c and form.c if you wish. | 14:40.05 |
| henrys | releasing soon is priority, if there were something very important to put in then we can delay more - but we commit to a February release and there are 2 days left. Just enough for the rc to fail and be fixed ;-) | 14:42.45 |
| paulgardiner | I have the opaque, text-highlight-markup problem fixed now. I guess I could have a go at this. It should be fairly quick provided it doesn't break partial update in some mysterious way. | 14:43.08 |
| | I am a little worried about breaking partial update. | 14:43.43 |
| | But I could try and if partial update is broken then let the release go without it. | 14:45.15 |
| | without the changes I mean | 14:45.30 |
| tor8 | paulgardiner: fair enough. | 15:01.14 |
| paulgardiner | unless we think a coupke of days freeze on other than bug fixes is safer | 15:02.32 |
| Robin_Watts | release now. | 15:02.52 |
| | fix later. | 15:02.56 |
| paulgardiner | Robin_Watts: tor8's checked my non-android commits (other than the one tiny one I just pushed). Be handy if you could give the android ones a check over. | 15:05.33 |
| Robin_Watts | looking now. | 15:07.07 |
| paulgardiner | ta muchly | 15:07.29 |
| Robin_Watts | How come ReaderView needs docHeight, but not docWidth ? | 15:09.59 |
| paulgardiner | I don't know. Eclipse told be it wasn't used. | 15:10.26 |
| Robin_Watts | indeed, it seems not to be. | 15:11.10 |
| | pdf_delete_annot... | 15:18.25 |
| | if you pass in an annot that's not in the page, you'll get bad results. | 15:18.45 |
| | and it'll crash if you pass annot == NULL | 15:18.56 |
| paulgardiner | Yeah, it would be safer to just return. I'll update that once you've done. | 15:20.47 |
| Robin_Watts | Suppose I delete an annotation, so it moves onto the deleted list. Then I do an update, so it moves onto the tmp list. Then I delete another annotation, and do another update. Won't the first tmp list get lost ? | 15:22.41 |
| paulgardiner | I see the problem with NULL. Would one not in the list be a problem? other than its being strange not to be there. | 15:23.01 |
| Robin_Watts | It's a sign that someone might be passing in an annot from the wrong page. | 15:23.21 |
| paulgardiner | Good point. | 15:23.33 |
| Robin_Watts | If you try to delete an annotation from the wrong page, nothing should happen. | 15:23.55 |
| | I'd vaguely prefer "death_row" to "tmp_annots" :) | 15:24.16 |
| paulgardiner | delete;update;deleteupdate is ok I think | 15:24.18 |
| Robin_Watts | how so? | 15:24.26 |
| | page->tmp_annots = page->deleted_annots | 15:24.34 |
| | delete A makes deleted_annots = A, A->next = NULL; | 15:25.18 |
| | update makes tmp_annots = A, delete_annots = NULL | 15:25.32 |
| | delete B makes deleted_annots = B, B->next = NULL | 15:25.42 |
| | update makes tmp_annots = B, delete_annots = NULL. Where has A gone ? | 15:25.57 |
| | "death_row_annots", better name than "death_row" actually. | 15:26.43 |
| paulgardiner | ah. Usage it to call update just before enumating the changed annotations. Next call to update will throw away ones you didn't enumerate. | 15:26.45 |
| Robin_Watts | ok, so it's safe because of usage. | 15:27.03 |
| | (that's internal usage, not usage by callers, right?) | 15:27.18 |
| | wierd indentation in jni/mupdf.c at line 1500ish. In "Android: implement annotation deletion" | 15:29.05 |
| paulgardiner | No external, but defined usage. The only way it was intended to work. You are about to do a partial update. You call update which handles all dirty widgets and sorting out the right appearance streams. Then you enumerate the changed annotations so that you know which rectangles to draw | 15:29.13 |
| Robin_Watts | Could we always update on the start of an enumeration to be sure? | 15:29.44 |
| | or would that be slow/break stuff? | 15:30.01 |
| paulgardiner | You also call update when you are about to draw the whole page, but then you don't want the rectangles, and you never will want the current ones | 15:30.02 |
| | update means prepare any dirty stuff and set up a list of annotations changed since the last update call in case I need them. | 15:31.53 |
| Robin_Watts | paulgardiner: Right. So if it's expected/assumed that you will always do that before starting an enumeration, can we not force an enumeration to do it anyway? | 15:32.35 |
| | Or would that redo work unnecessarily ? | 15:32.46 |
| paulgardiner | Possibly, but then you'd have to do the first step of enumeration even when you didn't need the result just to get the dirty things accounted for and to give you a starting point for the next call. | 15:33.43 |
| Robin_Watts | paulgardiner: I don't follow. | 15:34.09 |
| | I'm not saying we should remove update from the API. | 15:34.19 |
| paulgardiner | You mustn't call update twice before an enumation | 15:34.56 |
| Robin_Watts | Just that rather than designing an API that relies on us doing update before an enumeration, wouldn't it be nicer to not have that restriction? | 15:35.00 |
| | ah, why not? | 15:35.04 |
| | because then dirty rectangles might be lost ? | 15:35.37 |
| paulgardiner | Yes, and you want them to be in the draw-the-whole-page case. | 15:36.04 |
| Robin_Watts | paulgardiner: Ok, that sounds... fragile to me. | 15:36.19 |
| paulgardiner | What would be less so? given that not only do you want to avoid accidently missing a rectangle, you also want to avoid accidently drawing one that you already drew | 15:38.09 |
| Robin_Watts | (For the logs, sorted on the phone. My objection is withdrawn. One possible idea would be to rename 'update' to be 'prepare_for_redraw') | 15:50.10 |
| | paulgardiner: OK, the rest of the stuff looks good to me. | 15:51.55 |
| henrys | meeting in 5, coffee time | 15:53.32 |
| | looks like everything is moving along well. We should be able to have a quick meeting. | 16:00.14 |
| Robin_Watts | henrys: When we had to do the reflow, you said "do a PDF -> HTML extraction". | 16:01.13 |
| | Was that a requirement from the potential customer, or you thinking of the best way to get something going fast? | 16:01.33 |
| henrys | fast - I think there should be a longer term project to do native reflow but we don't have the bandwidth now. | 16:02.21 |
| Robin_Watts | It may be that we could get much better results by implementing our own scalable view. We'd get better font matching, better indents etc. | 16:02.57 |
| | OK. | 16:03.00 |
| henrys | I did want to bring up an overarching concern: have we done a careful feature check of the native android app and know what we are missing? | 16:03.59 |
| Robin_Watts | Of *what* native android app? | 16:05.02 |
| henrys | I'm looking at the nexus | 16:05.13 |
| Robin_Watts | There is no standard android app, it's different on every device. | 16:05.28 |
| | OK, the standard nexus app. I would assume we have not, as none of us 3 have a nexus. | 16:05.43 |
| henrys | but there is a standard pdf viewer that goes with the OS release - ice cream jelly bean etc. no? | 16:06.27 |
| paulgardiner | I think my S2 had Polaris Office | 16:06.32 |
| Robin_Watts | henrys: no. | 16:06.37 |
| | paulgardiner has been working on the annotation stuff with the intention of matching the mobile Adobe Reader thing, I think. | 16:07.04 |
| paulgardiner | That's been my initial target | 16:07.26 |
| Robin_Watts | Different vendors bundle different PDF apps with their kit. There is no standard app for us to match. | 16:07.36 |
| henrys | who is the vendor for native pdf on the nexus? | 16:08.23 |
| Robin_Watts | I have jelly bean on my transformer prime, and it has a different PDF app to jelly bean on the nexus, which is still different to jelly bean on the samsung SIII. | 16:08.39 |
| | henrys: I *think* it might be derived from Repligo? | 16:09.04 |
| henrys | so I guess the question is do those apps have any obvious important feature that we are missing and could put on Paul's todo list. | 16:09.53 |
| Robin_Watts | I think I'm right in thinking that Sony use QuickOffice, and that's recently changed to using Adobe as the PDF engine. | 16:09.57 |
| | henrys: Well, matching Adobe Reader for annotations seems like a good first step. | 16:10.37 |
| | mvrhel_laptop reported, IIRC, that reflow on on of his devices included images, but it was fairly braindead. | 16:11.10 |
| | (For every image on the page, stick it in the output). | 16:11.24 |
| henrys | yes that is in the works. I am asking if there is anything else we are sorely missing? | 16:11.29 |
| Robin_Watts | hence images used in patterns would appear as standalone images etc. | 16:12.11 |
| | I am not aware of anything missing from our app compared to the apps I've looked at, but can't claim to have done an exhaustive sweep. | 16:13.05 |
| paulgardiner | We're still behind Adobe Reader with annotatoin creation, but catching up. | 16:13.16 |
| Robin_Watts | Does Adobe Reader do forms or javascript? | 16:13.42 |
| henrys | next show it would be unpleasant to go through "Does it do this cool thing that this other app does?" again that's what I'm trying to avoid. I'll look at my app also. | 16:14.39 |
| paulgardiner | Robin_Watts: Strangely, it does forms without javascript. | 16:14.59 |
| henrys | all cool things should be implemented ;--) | 16:15.05 |
| | should we talk about the release this meeting? | 16:15.29 |
| | tor8? | 16:15.49 |
| Robin_Watts | I'd be happy for us to release now, as is, no further fiddling. | 16:16.28 |
| | The issue with mutool being a bit larger than we'd like is no biggy IMHO. | 16:16.41 |
| paulgardiner | I've had a quick look at what we discussed earlier (re unbloating mutool) and run into problems. | 16:16.49 |
| Robin_Watts | mutool users are running on the desktop, +/- 6Meg ain't going to matter a damn. | 16:17.16 |
| | It's nice to fix it if we can, but it doesn't make or break a release. | 16:17.49 |
| paulgardiner | I don't think we can quite as easily as we'd previously suspected. | 16:18.57 |
| henrys | phone call | 16:19.57 |
| | sorry I'm back | 16:21.29 |
| | seems like something that would get stuck in tor8's craw his okay with it? | 16:22.17 |
| paulgardiner | Robin_Watts: changes you requested are done and pushed. | 16:22.50 |
| henrys | so I'll just chase after tor8 sometime today about the release. | 16:23.49 |
| | thanks for the meeting | 16:24.05 |
| paulgardiner | cheers henrys | 16:25.28 |
| Robin_Watts | mvrhel_laptop: ping ? | 16:26.36 |
| tor8 | right, so release now | 16:26.39 |
| henrys | tor8:was that a question? | 16:27.26 |
| | if so yes | 16:27.31 |
| tor8 | henrys: it was an acknowledgement. | 16:27.40 |
| | Robin_Watts: with or without v8? how did we do with the tech preview release? | 16:27.47 |
| henrys | I do think mvrhel_laptop should start coming to the forms meeting - which should probably just become the mupdf meeting, but it might be early for him. | 16:29.04 |
| tor8 | mvrhel_laptop: do you have your windows 8 app in a git somewhere? | 16:30.01 |
| mvrhel_laptop | good morning | 16:31.25 |
| | tor8: I could add it in the mupdf project if you want | 16:31.36 |
| | I have it in my local copy | 16:31.44 |
| tor8 | mvrhel_laptop: you could do like I, robin and paul and host a personal repo on casper in ~/repos/mupdf.git | 16:32.26 |
| mvrhel_laptop | oh ok. I will do that then | 16:32.40 |
| tor8 | we have a rule that everything that hits the main repo has to go through a review by one other person | 16:33.22 |
| mvrhel_laptop | tor8: sounds reasonable. I will get my personal repo in place this week | 16:34.00 |
| tor8 | and your personal repo is yours to do with as you wish. rebase and amend commits freely. | 16:34.16 |
| henrys | hi marcosw | 16:34.56 |
| marcosw | morning henrys | 16:35.03 |
| henrys | I haven't really been following the bugs carefully do we need to go over them after the meeting or are they up to date? | 16:35.23 |
| | marcosw ^^^ | 16:35.34 |
| mvrhel_laptop | tor8 I think I have only one mupdf related change that I needed which is #ifdef __cplusplus extern "C" { #endif sort of thing | 16:35.56 |
| marcosw | I think we are up to date. There are a couple of minor issues assigned to support. | 16:36.08 |
| tor8 | mvrhel_laptop: extern "C" { #include "mupdf.h" } doesn't work for you? | 16:36.27 |
| mvrhel_laptop | in the fitz header | 16:36.28 |
| Robin_Watts | tor8: We should probably add that in the header. It's considered polite, I think. | 16:36.48 |
| tor8 | it's what we force the sumatrapdf folks to do :) | 16:36.52 |
| | ugh. I don't want to be polite to C++. | 16:36.59 |
| mvrhel_laptop | it did not work for some reason. I can go back and look again though | 16:37.02 |
| Robin_Watts | If there is no more mupdf business, I have a gs question for mvrhel. | 16:37.23 |
| mvrhel_laptop | I did try that at the time I remember | 16:37.24 |
| tor8 | considers adding variable names like "class" and "template". | 16:37.38 |
| mvrhel_laptop | :) | 16:37.46 |
| tor8 | mvrhel_laptop: if it doesn't work, knowing why would be good. if there's a valid reason we can add the ifdef c++, but my antipathy towards c++ would prefer not to | 16:38.31 |
| mvrhel_laptop | Robin_Watts: I can talk about gs | 16:38.33 |
| Robin_Watts | mvrhel_laptop: I've been looking at bug 693653, which is about a slowdown when using shadings. | 16:38.45 |
| | I think the basic reason for the slowdown is "we now do it properly". | 16:38.59 |
| mvrhel_laptop | tor8: ok I will reinvestigate this week | 16:39.03 |
| Robin_Watts | but in the discussion, alex has claimed that there is a problem with gx_icc_is_linear_in_line | 16:39.26 |
| | (see comment 12) | 16:39.29 |
| mvrhel_laptop | ok hold on | 16:39.36 |
| | Robin_Watts: I would need to see this running to know what is going on exactly. icclink->link_handle should have the number of input and output components | 16:42.17 |
| | and the output components should match the number of the device profile | 16:42.30 |
| | but let me take a closer look at remap_fast | 16:42.46 |
| Robin_Watts | mvrhel_laptop: I am assuming that the icclink passed in is somehow related to the cs and the device :) | 16:43.51 |
| mvrhel_laptop | yes. it is calculated early on in the shading code | 16:44.06 |
| Robin_Watts | Could the icclink not be calculated from the other params passed into this function? | 16:44.57 |
| | or would that take longer than just passing it in? | 16:45.08 |
| mvrhel_laptop | is there a case where ndes = gsicc_get_device_profile_comps(dev_profile) is not the number we are going out to? | 16:48.50 |
| Robin_Watts | I am not aware of one. | 16:49.14 |
| mvrhel_laptop | Robin_Watts: so the icclink is calculated way before we ever get to this point | 16:49.16 |
| Robin_Watts | but alexcher's comment lead me to think that maybe he had seen such a case. | 16:49.39 |
| | alex? | 16:49.42 |
| | mvrhel_laptop: Would this function be faster if we use remap_buffer rather than remap_color? | 16:49.51 |
| mvrhel_laptop | that would be very strange | 16:49.53 |
| | if we have a buffer of colors it would be faster | 16:50.03 |
| Robin_Watts | i.e. make 1 call for 3 colors into the ICC rather than 3 calls for 1 color each. | 16:50.26 |
| | In the next function, we make 7 calls, when we could make one. | 16:51.03 |
| mvrhel_laptop | oh yes this is the linear test stuff | 16:51.33 |
| | yes, we could pack them into a single buffer, transform and then do the linear test | 16:51.53 |
| | I don't know if with that few of colors if it will make much timing difference Robin_Watts | 16:52.13 |
| Robin_Watts | The whole bug is about decompose_linear_color taking a long time. | 16:52.28 |
| mvrhel_laptop | Robin_Watts: do we know what commit made it take a long time? I am wondering, since there were some shading bugs that I fixed in the last year where we were not doing things that we should have been doing. Those included transparency I think though. | 16:53.46 |
| Robin_Watts | Each time we recurse (to split the range in half) we check to see if the colorspace is linear in the required region. | 16:53.55 |
| mvrhel_laptop | Robin_Watts: yes | 16:54.02 |
| Robin_Watts | mvrhel_laptop: I know exactly what caused it to be slow :) | 16:54.07 |
| mvrhel_laptop | uhoh | 16:54.26 |
| henrys | it's probably slow because it is unlinear ;-) | 16:54.26 |
| Robin_Watts | originally (years ago, before I joined the company) the code used to decompose to single pixel level. | 16:54.43 |
| | Then (not so long ago, but still before I joined) it was changed to only decompose to 1pt accuracy. | 16:55.18 |
| | This was much faster, but less accurate. | 16:55.31 |
| | and noticeably so, so we got a bug report. | 16:55.51 |
| | so last year, I reverted the optimisation, with the option of having a #define in there to set MAX_SHADING_RESOLUTION, so people could opt for the faster speed if they wanted it. | 16:56.43 |
| mvrhel_laptop | I see. so you gave them a taste of speed | 16:57.20 |
| Robin_Watts | I thought it might be possible to use the MAX_SHADING_RESOLUTION trick in the case where we are using linear color fills, but having tested that, it produces unacceptable results (IMHO, see my bmpcmp page if you're interested). | 16:57.53 |
| | As it is, we now take 250 seconds instead of 4 (in the inaccurate, pre color corrected days), but we get it right. | 16:58.44 |
| mvrhel_laptop | oh yes the one image has some bad contours. some don't look too bad though Robin_Watts | 16:59.17 |
| alexcher | Robin_Watts: I'm back. | 16:59.25 |
| mvrhel_laptop | Robin_Watts: there is probably def. room for speed up in the linear check code | 16:59.57 |
| | especially if that is a hot spot that you are seeing | 17:00.05 |
| | I made no attempt to optimize at the time | 17:00.17 |
| Robin_Watts | mvrhel_laptop: At the moment, I'm still trying to get my head around the whole thing. | 17:00.23 |
| | alex: hi. | 17:00.27 |
| ray_laptop | how many times do we check to see if a colorspace is linear ? | 17:00.41 |
| mvrhel_laptop | as long as it is still nonlinear ;) | 17:00.54 |
| Robin_Watts | It's not "is the colorspace linear". It's "is the colorspace linear in this region". | 17:01.05 |
| | and we recheck repeatedly until the region is small enough that it's linear. | 17:01.24 |
| ray_laptop | can't we do a more complete check ONCE and mark it as linear (most colorspaces are pretty linear) | 17:01.34 |
| Robin_Watts | alex: in comment 12 you talk about ndes coming from the wrong place. Have you ever seen a case where ndes is the wrong value? | 17:01.59 |
| alexcher | Robin_Watts: Yes, in this bug. | 17:02.31 |
| Robin_Watts | ray_laptop: At every stage of the decomposition, if it's not already linear, we check to see if it has become so. | 17:02.33 |
| | hence a colorspace that is essentially linear throughout will only be checked once. | 17:03.10 |
| | alexcher: With this example file? Right. | 17:03.39 |
| mvrhel_laptop | if ndes is wrong, then that is a bug that I would like to look at. alexcher, is there anything special I need to do to catch this case? | 17:03.44 |
| alexcher | Only 1 output component is generated. The following code compares wild core for linearity. | 17:04.15 |
| henrys | chrisl:so I guess you have heard mupdf release is imminent hopefully | 17:05.12 |
| alexcher | mvrhel_laptop: I think I've posted everything. | 17:05.14 |
| mvrhel_laptop | alexcher: ok I will take a look at it | 17:05.35 |
| Robin_Watts | alexcher: You also talk about converting more colors at once by keeping them in a single array... is that to avoid repeated gsicc_remap_fast calls within the gx_icc_is_linear code ? or elsewhere? | 17:05.36 |
| chrisl | henrys: yep, I will keep an eye out for it | 17:05.53 |
| henrys | good to get it out before march 1 (rapidly approaching) | 17:06.16 |
| mvrhel_laptop | Robin_Watts: if you would rather me not poke into this since you have already started, I can back off and keep working on my windoze app. not sure what you have on your plate | 17:06.37 |
| chrisl | henrys: Doing the mupdf commercial release is trivial - takes only minutes | 17:06.46 |
| alexcher | Robin_Watts: Yes. Probably this will not be so significant when other errors are fixed. | 17:06.55 |
| Robin_Watts | mvrhel_laptop: I'd appreciate you looking at it, if you wouldn't mind. | 17:07.23 |
| | I can see various places where we can safe some time, but no massive algorithmic fixes. | 17:07.53 |
| | s/safe/save/ bah. | 17:08.01 |
| mvrhel_laptop | Robin_Watts: ok. first I will look at seeing if I can catch the ndes issue | 17:08.18 |
| henrys | we don't think a profile is needed with 693653? | 17:08.25 |
| Robin_Watts | henrys: I'll do a profile, but it would be better to profile after the known bugs are fixed. | 17:09.03 |
| henrys | okay | 17:09.25 |
| Robin_Watts | I'm gonna have to run away for about 10 minutes in the next 10 minutes or so - anyone want me for anything? | 17:09.31 |
| alexcher | Robin_Watts: There's another problem there. I've initialized the arrays, i.e. made this code work a little close to the original intent. And another branch broke completely. | 17:09.39 |
| kens | Not me | 17:09.39 |
| henrys | Robin_Watts: fine for me. | 17:09.53 |
| | ray_laptop:have you inherited smask? | 17:10.05 |
| | my initial thinking was alexcher would do the work with help from others. but if you have the cycles ... | 17:10.50 |
| Robin_Watts | alexcher: This is the "cleaning the buffers" thing? | 17:10.51 |
| mvrhel_laptop | henrys: before we profile, let me see if I can catch the bug that alexcher mentioned. if the ndes values is wrong, then that would/could give wacky results | 17:10.57 |
| henrys | mvrhel_laptop: okay | 17:11.22 |
| | kens:I'm going to check in the xps code shortly but I'll probably just continue working on it. I've grown fond of it. | 17:11.53 |
| mvrhel_laptop | he has been assimilated. | 17:12.10 |
| alexcher | Robin_Watts: Initializing first 3 elements is enough. | 17:12.19 |
| Robin_Watts | alexcher: OK. so we should understand/fix that too before I profile. | 17:13.10 |
| henrys | I have had a chance to dive into the XPS C API - it is very difficult for me to believe folks are going to relatively their fairly simple gdi code without extreme pressure from MS | 17:13.15 |
| | s/relatively/change | 17:13.47 |
| kens | THe XPS API is OK, I had to reaqd it a bit to get the printing going | 17:13.49 |
| | ]From my POV I'm done with XPS printingfor now, I cna take an existing XPS file and print it to a designated printer | 17:14.20 |
| | SO for a GSPrint, we just need to run xpswrite to generate an XPS file, then send it to the printer. | 17:14.48 |
| alexcher | Robin_Watts: Currently profiling shows that about 30% of time is spent by LCMS, but this happens because the shading is decomposed into smallest possible fragments. | 17:15.13 |
| kens | If you wanted a tighter integration we could do something that builds an internal XPS file. | 17:15.18 |
| ray_laptop | henrys: sorry -- I was working on the changes, but Yes, I took the SMask bug and know how to make it work | 17:15.27 |
| kens | henrys but I htink an xpswrite device should not be tied to the WIndows API :_) | 17:15.43 |
| henrys | kens:oh okay can you set arguments though, so we can fix the bugs? | 17:15.46 |
| | kens:certainly not | 17:15.54 |
| kens | henrys, at the moment my code just takeds an existing XPS file | 17:16.12 |
| | THere aren't really any arguments to give, other than the printer name | 17:16.24 |
| | If you want flourishes we can pop up a printer dialog to set up the printer defaults | 17:16.41 |
| chrisl | ray_laptop: can I ask you a cust 532 question? | 17:16.48 |
| ray_laptop | chrisl: sure -- do we need a private chat ? | 17:17.26 |
| henrys | kens:what I meant about difficult is creating an xps document. It is horribly complex a bizillion objects to do very simple stuff, I don't think that is going to fly unlesss microsoft pulls out gdi | 17:18.01 |
| chrisl | ray_laptop: No I don't think so - their latest font bug is a broken CFF that the "new" C parser fixes. Are we happy giving them that as a 8.71++ patch? | 17:18.14 |
| ray_laptop | chrisl: as long as it builds with their pre 9.00, sure | 17:18.58 |
| kens | henrys, yes certainly creating an XPS file is hard and complex (like writing a PDF file but with no advantages). You can make an internal XPS document comparatively easily using the WIndows API though. But I agree, as long as there is a legacy path, (ie GDI) nobody is going to use the XPS pritn path | 17:19.12 |
| ray_laptop | chrisl: note that they _are_ moving to 9.0x and so it's only a patch on the older products (that are already heavily patched with fixes that are now in 9.0x) | 17:19.48 |
| chrisl | ray_laptop: Yep, I've got it integrated and seems to be working. But I was going to leave the "heavy" testing to them...... | 17:19.49 |
| ray_laptop | chrisl: yes, they will run it through their QA process, but if you tell them the nature of the changes and what to check (i.e. all text) then that might help them | 17:21.14 |
| chrisl | ray_laptop: yeh, I'll do that | 17:22.11 |
| henrys | kens:can you override the page size? see http://bugs.ghostscript.com/show_bug.cgi?id=691921 comment 5 | 17:22.21 |
| ray_laptop | chrisl: you should also let them know that it is already fixed in the newer code, and that we have extensively tested it in 9.0x | 17:22.43 |
| | chrisl: which release had this ? | 17:22.58 |
| kens | henrys We can certainly pop up a print dialog so that the suer can select the appropriate media | 17:23.00 |
| chrisl | ray_laptop: 9.00 introduced the C CFF parser | 17:23.25 |
| kens | I haven't gone that far because I wanted to talk to you about how you saw this going. Maybe we can talk at the meeting in 2 weeks | 17:23.26 |
| henrys | kens:I thought they were aware of that but wanted unattended processing, maybe marcosw remembers. | 17:23.43 |
| kens | henrys I *think* we cna set up a XPS job ticket, but again I haven't looked at this in detail to see whatr's in it | 17:24.13 |
| henrys | they can pop up the printer dialog now. | 17:24.15 |
| ray_laptop | chrisl: OK, thanks. So you can tell them that the 9.06 code they have been testing has this same code. That will help them feel more comfortable | 17:24.23 |
| kens | henrys, no, they have to set up the prtiner *default* before starting | 17:24.28 |
| chrisl | ray_laptop: sure will do | 17:24.40 |
| kens | In our case we would pop up a dialog after starting to print, and user can select settigns for that print job only | 17:25.09 |
| | henrys, I'll make a point of reading the docs before the meeting so I can talk sensibly about this again, its been a few weeks since I last looked into this | 17:25.55 |
| henrys | kens:I imagine the printer default is set once and left alone - then they want batch (no interaction) processing, but I am not 100% | 17:25.56 |
| kens | henrys, this is the sort of thing I wanted to discuss :-) What exactly we want this 'GSPrint replacement' to be able to do.... | 17:26.32 |
| | I'll look at the job ticket and see what control we have | 17:26.51 |
| henrys | mvrhel_laptop: do you think you can start making the mupdf meetings, be nice to have you weigh in since you are working on the windows platform. | 17:27.15 |
| | ? | 17:27.16 |
| mvrhel_laptop | henrys: yes what time are they? | 17:27.37 |
| kens | 1 hour before this one :-) | 17:27.46 |
| henrys | an hour before the gs meeting | 17:27.47 |
| mvrhel_laptop | henrys: sure. I will plan on it | 17:28.10 |
| henrys | great | 17:28.17 |
| | kens:I'll look at the print stuff also. | 17:29.09 |
| | kens:I was thinking the printer would be a windows only device and a subclass of xpswrite, but I don't know what sort of minefield that will be. | 17:31.29 |
| kens | henrys yes I was assuming it would be a winpdws only thing | 17:31.46 |
| | I would suggest adding it as a bolt-on to xpswrite, but subclass works too | 17:32.09 |
| | I was thinking in terms of having xpswrite create a temp file, then xpsprint sending it to the printer, then deleting the file. | 17:32.35 |
| | so xpswrite would remain unchanged | 17:32.49 |
| henrys | yes it uses the regular outputfile mechanism now | 17:33.19 |
| kens | THat was what I was thinking. If we write to a temp location we can then print the file and finally delete it | 17:33.43 |
| henrys | other stuff for the meeting we are 3 minutes over | 17:33.44 |
| | you're still plugging away on cm yes? | 17:34.14 |
| | kens ^^^ | 17:34.20 |
| kens | henrys yes afraid so | 17:34.30 |
| | Currently constructing a test file for all possible combinations of colour spaces, vector and images | 17:34.46 |
| | Bascially it works right now, but I haveto test all the edge cases, then start adding enhancements | 17:35.12 |
| henrys | right | 17:35.41 |
| kens | I can now test all spaces with vectors and type 1 images | 17:35.50 |
| | Still to do imagemasks (don't expect problems) and type 3 and 4 images | 17:36.06 |
| | THen I cna look at 12 and 16 bit images, which we handle very badly at present | 17:36.23 |
| henrys | 693663 is definitely a problem for PXL because the resolution options are really just 300 and 600. | 17:41.00 |
| kens | Ah crap the print ticket is in XML :( | 17:41.03 |
| henrys | kens:you were expecting ??? | 17:41.19 |
| kens | expceting XML, hoping for somethign nicer :-( | 17:41.37 |
| Robin_Watts | It shows a certain consistency that Microsoft are not known for :) | 17:41.51 |
| kens | henrys 693663 he should set the resolution to 300 then | 17:41.52 |
| | Or get more memory | 17:42.24 |
| | OK off to make dinner, bye all | 17:42.55 |
| henrys | chrisl, alexcher: have we really looked into these cairo files to make sure we can't be more lazy about installing pdf14? I guess we did look at that a while back. | 17:44.41 |
| | oh wait ray_laptop was going to have banding for all devices and then cleverly mark bands transparent. right? | 17:45.58 |
| | so 693663 should say the problem will be fixed when that is done, yes? | 17:46.49 |
| chrisl | henrys: yes, we did look at spotting such "pointless" transparency, but for a reason which currently escapes me, we concluded it wouldn't work - too slow, for "real" files | 17:47.22 |
| | IIRC, one of the files I looked at contained an all opaque softmask, so we'd need to process all the samples to check it, but I think there were other issues with other files | 17:48.58 |
| Robin_Watts | henrys: ps2write doesn't support banded operation (nor does pdfwrite). hence any magic trickery that ray may do in the clist will not help those cases. | 17:49.26 |
| chrisl | Robin_Watts: the plan is to use a clist for the transparency flattening for those devices | 17:49.58 |
| Robin_Watts | so the devices would use the clist without knowing they were using the clist ? | 17:50.19 |
| chrisl | They'd probably need updated to accept the flattened groups in bands, if required | 17:51.07 |
| mvrhel_laptop | alexcher: so I am running the test file with a gray device, and I never see a case where ndes is not 1. what do I need to do to see the issue you mentioned? the comments in the bug do not provide any guidance | 17:51.10 |
| henrys | well I thought he was going to do something like the pattern clist machinery, but ray_laptop should answer | 17:51.25 |
| ray_laptop | henrys: I have the 'cleverly mark bands' for transparency. | 17:51.56 |
| henrys | the question is will it work with any device? | 17:52.33 |
| ray_laptop | henrys: and putting in a clist for "other" devices is on the list (when the bitmap exceeds the MaxBitmap setting) | 17:52.37 |
| henrys | So the answer to 693663 is: it's in the works | 17:53.26 |
| | not: go away | 17:53.35 |
| chrisl | henrys: sure that is covered in 689805? | 17:55.07 |
| mvrhel_laptop | alexcher: any hints on where and how you see the issue with ndes, would be much appreciated | 17:55.36 |
| henrys | chrisl: oh okay right, I can shutup now. | 17:55.58 |
| ray_laptop | henrys: the goal is to work with any raster device. High level devices that render transparency to a memory device will use it | 17:56.41 |
| chrisl | I guess ken's comment could have made it clearer that we have a plan being tracked under 689805 | 17:56.48 |
| henrys | ray_color:okay so pxcolor will need work to use it. | 17:57.28 |
| ray_laptop | high level devices that handle transparency directly (that grab the pdf14 compositor actions) won't use it | 17:57.41 |
| | henrys: "high level" devices like pxlcolor render transparent pages to a bitmap. The default pdf14 compositor in gdevp14.c snags all drawing operations and the pxlcolor device only gets called at end of page with a full page bitmap | 17:59.23 |
| henrys | ray_laptop:I take that back pxcolor will work | 17:59.41 |
| | oh what you said | 17:59.46 |
| ray_laptop | henrys: probably will work without mods. Note that this will NOT work without mods to use clist to render large bitmaps that don't use transparency | 18:00.54 |
| henrys | got it | 18:01.51 |
| ray_laptop | but to add this for really large bitmaps to something like the display device won't be too bad, but "normal" painting operations to 'vector' devices won't get picked up unless the page uses transparency | 18:02.18 |
| alexcher | mvrhel_laptop: gs -r87 -sDEVICE=bmp16m -o /dev/null enac1.pdf | 18:20.07 |
| | mvrhel_laptop: Just put a breakpoint in gx_icc_is_linear_in_line(). The first break has this problem. | 18:21.19 |
| | mvrhel_laptop: I'm using 64-bit Linux. 32-bit Linux is also slow. | 18:22.04 |
| mvrhel_laptop | ok. so is bmp16m gray? | 18:23.16 |
| alexcher | mvrhel_laptop: No, it's RGB. | 18:23.29 |
| Robin_Watts | mvrhel_laptop: No. | 18:23.34 |
| mvrhel_laptop | ok so ndes is coming out as 3 for me | 18:23.39 |
| | which I would expect | 18:23.47 |
| | I thought the issue was a gray issue | 18:24.02 |
| | I need to head out now unfortunately for about an hour to the kids school | 18:24.15 |
| alexcher | mvrhel_laptop: But CMS generates only 1 component. | 18:24.22 |
| mvrhel_laptop | ok let me step in there real quick | 18:24.42 |
| | ok. yes. there is an issue | 18:25.55 |
| | I wonder if there is something going wrong because of the 16 bit case | 18:26.14 |
| | I will look at this more when I return now that I can see | 18:26.27 |
| | thanks alexcher | 18:26.36 |
| Robin_Watts | paulgardiner: ping | 18:40.29 |
| malc_ | tor8: hi, hit a very interesting issue today, after some transform_rect (for a very tall argument 10K+ pixels high), the result has a height of 6.. furthermore i can not reproduce it on my home machines (not on x86_64 neither on ppc32), perhaps that rings any bells for you? [oh and futhermore mupdf on that other machine which i will only have access tomorow kills X (the pdf contains only one page, though this one page is rather gargantuan hight wise, this | 19:07.01 |
| Robin_Watts | malc_: What architecture were you seeing the strange result on ? | 19:20.41 |
| | Can we see the file? | 19:20.50 |
| malc_ | Robin_Watts: x86_64, it's just a pango-view -o moo.pdf output of some ~7.5KLOC source file, since i'm not sure what fonts were embedded the file would have to wait till tomorow | 19:22.21 |
| | Robin_Watts: i sortof ruled out optimization problem given that same thing happens with debug and release builds and both gcc and clang produced binaries exhibit same behavior | 19:23.17 |
| | pretty weird if anyone would have been interested in my opinion | 19:23.28 |
| Robin_Watts | malc_: Well, it's probably an overflow of some sort, obviously. | 19:24.00 |
| malc_ | given that mupdf is not really gcc -Wall friendly it might be | 19:24.44 |
| Robin_Watts | http://ghostscript.com/~robin/MuPDF-9.apk <- New android build for testing. | 19:29.18 |
| malc_ | Robin_Watts: btw. any answer to the question i asked few days ago? | 19:33.34 |
| | apparently not | 19:43.46 |
| ray_laptop | mvrhel_laptop: do you have a file laying around that has nested SMasks ? (or Robin_Watts) ? | 20:15.36 |
| | I have the test_smask2.pdf rendering correctly now. Two simple changes | 20:16.39 |
| | the changes ended up being almost what I thought was needed last week when I dove into this, but finding out where in the mess to put them took the time (PS debugging is much harder than C, so I spent too much time tracing the C code) | 20:18.08 |
| | I sure am glad user jobs jump in ahead of commit tests :-) | 20:31.15 |
| | letting the cluster tell me what my changes break | 20:44.56 |
| Robin_Watts | ray_laptop: Excellent! | 20:52.18 |
| | No, I don't have any such files (that I know of), sorry. | 20:52.30 |
| ray_laptop | Robin_Watts: np. The cluster pointed me to some differences that I need to investigate. I'm hoping that many will be progressions, but that is just my optimistic nature ;-) | 20:55.24 |
| Robin_Watts | ray_laptop: Have you bmpcmp'd ? | 21:03.55 |
| mvrhel_laptop | ray_laptop: I can't find the bug that had the softmask in softmask file | 21:09.59 |
| | I think it is in the data base though | 21:10.07 |
| | the regression suite I mean | 21:10.17 |
| | ok. so the issue with ndes is a pdf14 color chameleon issue | 21:14.33 |
| | As I suspected | 21:14.41 |
| | should be easy to fix this | 21:15.02 |
| | bbiab | 21:15.05 |
| ray_laptop | I have the file Bug690535.pdf that shows problems. Starting with that one... | 21:18.41 |
| | time for lunch... | 21:19.01 |
| Robin_Watts | ray_laptop: Did you run bmpcmp ? | 21:19.39 |
| xreal | Can I convert fonts to paths and keep copying chars? Acrobat can do I this. | 21:40.51 |
| | Forward 1 day (to 2013/02/27)>>> | |
IRC Logs