| | <<<Back 1 day (to 2016/07/13) | 20160714 |
| sebras | Robin_Watts: tor8: ok. so I have updated sebras/master again after doing the vim wizardry (:%s/\<\([a-z]\+\)_\>/j\1/g) and then renaming jstring jstring to jstring jstr, I conversely changed the naming in the Java code from String string to String str. | 04:16.52 |
| | we're talking about Text.showString() here so I guess the String in the method name is the reason the argument was named string. now it's str which matches with the JNI code. :) | 04:17.47 |
| | ok, so after this back and forthing, is there anything else or does it LGTY? | 04:19.02 |
| Robin_Watts | sebras: We now seem to have jcolorspace/cs rather than jcs/cs | 09:18.08 |
| | and jshade/shd rather than jshd/shd | 09:18.22 |
| | but that's very minor. I say commit it, and we can maybe fix them in followups. | 09:19.47 |
| | My objections to PDFDocument and PDFObject still stand, but again, I reckon we should commit and fix it up later. | 09:21.42 |
| | and the third commit seems fine too. | 09:22.15 |
| | Can we arrange for the font +/- buttons to only appear in epub files? | 09:22.46 |
| kens | tor8 ping | 10:33.20 |
| tor8 | kens: yes? | 10:42.01 |
| kens | coommit on my repo for the XPS thing if you wouldn't mind looking please | 10:42.23 |
| tor8 | Robin_Watts: fz_is_reflowable(doc)? | 10:42.30 |
| kens | http://git.ghostscript.com/?p=user/ken/ghostpdl.git;a=commit;h=fd1b84560536076f655421e98a27e58d2881ca70 | 10:42.33 |
| | tor8 there's also a bmpcmp of the diffs if you wold like ot look at that too | 10:42.59 |
| tor8 | the bmpcmps look like progressions :) | 10:48.01 |
| kens | for pdfwrite, they are | 10:48.13 |
| | seems we only test xps at 72 dpi | 10:48.31 |
| | and fo course the synthetic bold doesn't show any differences at such a low resolution | 10:49.23 |
| | I did run some test earlier with stupidly large stroke widths, and with filling disabled, just to prove to myself that the code was working as expected | 10:50.09 |
| tor8 | kens: I confess I have no idea how PDF's separate stroke/fill colours are handled | 10:50.14 |
| kens | tor8 not as well as I would like :) | 10:50.24 |
| tor8 | the XPS code only does gs_setcolor for everything | 10:50.28 |
| kens | Yeah I know | 10:50.33 |
| | There's normally no reason for XPS to care, because it doesn't have separate stroke and fill colours, but for text rendering modes involving stroke, we need the stroke colour | 10:51.06 |
| tor8 | do we need to save/restore the stroke colour at all? | 10:51.22 |
| kens | I do :-) | 10:51.27 |
| | RIght at the ned of the funciton I put it back | 10:51.39 |
| tor8 | I mean, is that even necessary? | 10:51.51 |
| kens | Only so that the reference counting works out | 10:51.54 |
| | If you don;t then memory handling goes haywire | 10:52.08 |
| tor8 | ah, right. it refers to colourspaces etc. safer to do so than not. | 10:52.10 |
| kens | :) | 10:52.14 |
| tor8 | all LGTM then. thanks for fixing this! | 10:52.21 |
| kens | Ideally I'd set the stroke colour 'properly' butthat's a lot of effort for such a minor fix. OK I'll commit it then, thanks tor8 | 10:52.48 |
| tor8 | my only objection would be invoking the param list read/write on every fake bold text operation | 10:53.11 |
| | that does seem a bit wasteful | 10:53.28 |
| kens | Yeah its icky and rather expensive | 10:53.29 |
| | FWIW we do the same thing in the PDF interpreter (from PostScript yet!) and its not too expensive | 10:53.54 |
| tor8 | you could cache the value in the xps_context, but it shouldn't be too bad. a hundred times a page at most, I reckon. | 10:54.22 |
| kens | If we encoutnered this a lot it would be something we could carry around, set oncce and consult as needed | 10:54.31 |
| | But it seems not that common | 10:54.41 |
| tor8 | I wouldn't worry about it. using BoldSimulation *should* be punished! :) | 10:55.12 |
| kens | LOL :-D | 10:55.22 |
| | I did consider just always doing a stroke and not using Tr at all, but this seemed nicer | 10:55.45 |
| | Well, nicer for PDF output | 10:56.12 |
| tor8 | yeah, if it comes out as Tr 2 on PDFwrite then that's a lot more in line with what people would expect from the main use of gxps which I gather is converting to PDF | 10:56.22 |
| kens | It does seem to be, which is slightly worrying.... | 10:56.41 |
| | OK back to PDF graphcis states :-( | 10:57.31 |
| tor8 | sebras: PDFObject.java will need toNumber, toReal, toInteger, toBoolean, etc as well | 11:50.44 |
| | sebras: things that JS doesn't need because of the automatic use of toValue when coercing types | 11:51.09 |
| | and toName | 11:51.25 |
| Robin_Watts | tor8: seems reasonable. | 12:12.15 |
| | (the fz_is_reflowable thing) | 12:12.25 |
| | rayjj: For the logs: Updated transpose commit on robin/master | 13:06.12 |
| | A debug build runs the command line given by marcos in 46seconds for me, rather than the 34 minutes he claims. | 13:15.25 |
| sebras | Robin_Watts: how can I find out if a fz_document is an epub? | 13:30.28 |
| tor8 | sebras: I suggested adding a fz_is_document_reflowable type function | 13:31.29 |
| sebras | tor8: what do we return for pdf? | 13:31.59 |
| tor8 | sebras: a few more comments from me in the log about PDFObject | 13:32.06 |
| | false? | 13:32.11 |
| sebras | tor8: but it is reflowable some times? | 13:32.22 |
| tor8 | only return true for html and epub | 13:32.23 |
| | it is never reflowable. the "reflowable" thing in the android viewer just runs a pdf-to-html conversion and drops in a web view | 13:32.53 |
| sebras | tor8: but the format itself does provide reflowindicators, no? | 13:33.18 |
| | tor8: whether we want to support that in the end is a different matter. | 13:33.32 |
| tor8 | it can, but we don't do anything about them | 13:33.36 |
| sebras | I' | 13:33.36 |
| | I'm guess no. | 13:33.39 |
| | tor8: oh, your comments were quite recent. | 13:34.50 |
| | tor8: I'll do an doc->is_reflowable flag that is only set by the constructors of html and epub. | 13:43.58 |
| | no need for a functionpointer for that. | 13:44.09 |
| | as it never changes. | 13:44.12 |
| tor8 | sebras: sounds good. | 13:44.20 |
| sebras | tor8: hm.. toFloat or toReal()? | 14:10.27 |
| | tor8: the type will be float, so I'd vote for toFloat(). | 14:10.36 |
| | tor8: also, toString() is kind of already occupied. how about toStr()? | 14:10.54 |
| | also I'm thinking that toStr() should work for both string and name pdf objects. | 14:17.52 |
| | that's how I'd expect it to work. | 14:18.09 |
| | do we also want a toNull() that returns NULL if the object is a null object and returns non-NULL otherwise? ;) | 14:18.34 |
| | on a more serious note we might want to expose PDFObject.isNull() though. similar to PDFObject.isIndirect()? | 14:19.47 |
| | that would make sense to me. | 14:19.50 |
| tor8 | sebras: yes. all of the ones needed for C should be here too. | 14:24.25 |
| | rename the current toString() into toPDFString perhaps? not sure. Robin_Watts may want to weigh in here. | 14:26.04 |
| sebras | tor8: well.. that depends on how you want to print stuff..? | 14:26.53 |
| | System.out.println(PDFObject) should print what? | 14:27.05 |
| | System.out.println(java.lang.Integer) prints the value right? | 14:27.54 |
| | instead of the L[java.lang.Integer@376473 string I'm guessing. | 14:28.13 |
| | yup. | 14:28.45 |
| tor8 | sebras: hm, right. byte[] toByteString and char[] toUnicodeString then? | 14:29.08 |
| | toString should return the byte array, toName should return a java string | 14:29.44 |
| | toUnicodeString should be equivalent of pdf_to_ucs2. that's an area where mujs needs fixing though. | 14:31.01 |
| sebras | for a PDFObject which is a number, say 42, wouldn't we want PDFObject.toString() to return "42"? so that System.out.println(PDFObject) would indeed print "42\n"? | 14:31.09 |
| tor8 | yes | 14:31.19 |
| | toString should turn it into PDF syntax, IMO | 14:31.29 |
| sebras | ok, so you gave up on toPDFString()?! ok. :) | 14:31.53 |
| | s/^ok/oh/ | 14:32.03 |
| tor8 | sebras: yeah. when you pointed out println I gave up that idea | 14:33.54 |
| | sebras: for mujs, toString returns a formatted string and toValue returns an equivalent js type | 14:34.32 |
| sebras | I'll skip toUnicodeString() for now if that's ok. | 14:34.34 |
| | tor8: what does formatted mean in this context? | 14:34.54 |
| tor8 | pdf_sprint_obj | 14:35.12 |
| | sebras: gotta go, be back later tonight (your morning perhaps) | 14:36.03 |
| sebras | Robin_Watts: you about? | 15:56.37 |
| | or tor8 for that matter. | 15:56.47 |
| | there is a problem in e.g. NativeDevice_fillPath() where early on it does fz_matrix ctm = from_Matrix(env, jctm); but nothing prevents jctm from being NULL and if it is then fromMatrix() calls (*env)->GetFloatField() which ends up segfaulting. | 15:58.14 |
| | the same issue exists with from_Rect() in e.g. NativeDevice_beginMask() | 15:58.36 |
| | I'm contemplating declaring all arguments doing the NULL check for ctx and non-optional arguments and first after that doing the calls to from_*() before continuing with the rest of the function. | 15:59.37 |
| | also if e.g. jctm == NULL do want to throw a java exception, or do we want to silently return NULL? | 16:00.46 |
| | I _could_ move only the from_Matrix() and from_Rect() calls of course, but that makes argument checking a bit spread out. | 16:04.06 |
| | ugh... this patch never ends. :( | 16:04.15 |
| Robin_Watts | sebras: Yes, here now. | 16:06.58 |
| sebras | Robin_Watts: opinion on theabove? | 16:10.33 |
| Robin_Watts | sebras: Sorry, too many threads. looking now. | 16:11.35 |
| | sebras: jctm == NULL should be equivalent to fz_identity_matrix. | 16:12.11 |
| | That's what all (*) the rest of the code does (* for some definition of all). | 16:12.25 |
| sebras | Robin_Watts: ok, that resolves from_Matrix(). from_Rect() is treated as { 0, 0, 0, 0} in the normal c-code? | 16:13.18 |
| | Robin_Watts: doing that gives me a way to resolve this without rearranging too much. | 16:13.39 |
| Robin_Watts | fz_empty_rect, I believe. | 16:13.45 |
| | Well, actually, not sure that we have a sensible default for fz_empty_rect :( | 16:14.05 |
| | for rect == NULL, I mean. | 16:14.17 |
| sebras | Robin_Watts: ok. I think it would be ok to assume fz_empty_rect in the Java code. | 16:14.42 |
| | simply because it makes the bindings easier. :) | 16:15.03 |
| Robin_Watts | I think doing something sane and simple wins when we can't think of a compelling reason not to. | 16:15.28 |
| | so yes. | 16:15.31 |
| | sebras: With this stuff, feel free to commit it and then refine it. Don't feel you have to shoot for perfection all at once, cos otherwise it will never end :) | 16:16.11 |
| sebras | Robin_Watts: well... I keep getting review comments, so my shooting is apparently off target. ;) | 16:22.34 |
| | Robin_Watts: hm.. in fz_new_image_from_pixmap() if mask == NULL and fz_new_image() fails, we attempt to fz_drop_image() our mask, but this is NULL and will subsequently dereference NULL, right? | 16:58.11 |
| | oh, and having a pixmap without a mask is fully valid I presume. | 16:58.30 |
| Robin_Watts | No. | 16:58.31 |
| sebras | Robin_Watts: why? | 16:58.37 |
| Robin_Watts | Every destructor in MuPDF is specced to accept NULL. | 16:58.52 |
| | fz_drop_blah(ctx, NULL); is always fine. Makes cleanup code MUCH easier. | 16:59.11 |
| sebras | void fz_drop_image(fz_context *ctx, fz_image *image) { fz_drop_storable(ctx, &image->storable); } | 16:59.16 |
| | how is it ok if image == NULL ? | 16:59.23 |
| Robin_Watts | &image->storable == NULL | 16:59.32 |
| sebras | no, no... image == NULL. | 16:59.58 |
| Robin_Watts | yes. image == NULL. Therefore &image->storable = NULL :) | 17:00.15 |
| sebras | what?! why? | 17:00.23 |
| Robin_Watts | storable = a structure at the start of the image structure :) | 17:00.36 |
| | &image->storable == image | 17:01.14 |
| | it just has a different type. | 17:01.22 |
| sebras | ok, so offsetof(fz_image, storable) == 0, that's basically the trick here. | 17:01.33 |
| Robin_Watts | Yes. | 17:01.39 |
| sebras | right. | 17:01.49 |
| psmlbhor | I am trying to learn mupdf. I have used ghostscript before. So I want to know whether mupdf supports all the switches that are supported by ghostscript? | 17:47.52 |
| Robin_Watts | psmlbhor: It does not. | 17:50.55 |
| | ghostscript is primarily a postscript interpreter that also does PDF files. | 17:51.27 |
| | MuPDF does not support postscript, but it does support PDF, XPS, JPEG, PNG, CBZ, etc. | 17:52.10 |
| | mupdf is at heart a portable C library for opening/manipulating/rendering such files. It is built into several example tools. | 17:52.55 |
| | For a start you should decide which tool to work with (or whether you want to write your own code that calls the C library). | 17:53.22 |
| | If you want a simple viewer on windows or x11, then you want "mupdf". If you want a gl based viewer, then "mupdf-gl". | 17:53.49 |
| | If you want to just render to images, then "mutool draw" | 17:54.00 |
| | The switches available on each are very different, and are (broadly) unrelated to those available for ghostscript. | 17:54.25 |
| psmlbhor | Robin_Watts, I want to work with PDF files. I want to take PDF data and convert it to some other data format using C. What might be best thing to do for such a task ? | 17:55.59 |
| Robin_Watts | psmlbhor: You probably want to take mudraw.c or muraster.c as examples. | 17:56.25 |
| | or even look at doc/example.c | 17:56.46 |
| | docs/example.c, sorry. | 17:57.01 |
| psmlbhor | Robin_Watts, I looked at example.c but couldn't decide whether to do it that way or make some command line and execute it. I will take a look at muraster.c and mudraw.c as you have suggested | 17:57.40 |
| Robin_Watts | That shows how to open a document, and render to memory, which is then written out as a ppm. | 17:58.13 |
| | When you say "some other data format" you mean a bitmap data format? | 17:58.39 |
| psmlbhor | PWG raster format | 17:58.52 |
| Robin_Watts | OK. mutool draw -o out.pwg -r200 in.pdf | 17:59.12 |
| psmlbhor | Oh! that seems quite easy. I want to learn more about the options mutool supports. Are they all covered in the man pages ? | 18:00.49 |
| Robin_Watts | psmlbhor: Run with no arguments, and the options are listed. | 18:01.15 |
| psmlbhor | Robin_Watts, yes that worked. Thanks for you help | 18:01.44 |
| Robin_Watts | np. | 18:01.48 |
| sebras | Robin_Watts: tor8: ok, so a set of revised patches over at sebras/master. | 18:12.43 |
| Robin_Watts | how did your test go, btw? | 18:12.57 |
| sebras | I have also removed the PDFOBject.doc pointer. | 18:13.02 |
| | Robin_Watts: I don't know yet, but I know I messed up a few things. I'll let you know when I get it back. presumably tomorrow. | 18:13.48 |
| Robin_Watts | The doc_is_reflowable one looks good. | 18:14.00 |
| sebras | pointer?! in java?! I meant reference. :) | 18:14.05 |
| Robin_Watts | The cleanup looks good. | 18:14.40 |
| | All of them look good. Excellent stuff! | 18:16.31 |
| sebras | Robin_Watts: public const static final commit; commit.push()? | 18:17.00 |
| Robin_Watts | return true; | 18:17.19 |
| sebras | Robin_Watts: or as the grammar that I have been taught the last few weeks "today I push not push commit?" | 18:17.47 |
| Robin_Watts | sebras: There is a promising career ahead of you in writing instruction booklets. | 18:18.21 |
| sebras | Robin_Watts: :) | 18:18.46 |
| | Robin_Watts: learning a bit has at least taught me why certain mistakes are done in English by people who are native Mandarin speakers. | 18:19.29 |
| | fredross-perry: my batch of commits has been pushed now. so feel free to rearrange the java code as you see fit. :) | 18:26.35 |
| fredross-perry | OK swell, i'll get to that now. | 18:26.57 |
| sebras | yey, all commits passed in the cluster. ok. I' | 18:58.20 |
| | m off. | 18:58.22 |
| Robin_Watts | cu | 18:59.59 |
| fredross-perry | robin - It looks like caafb37ddf3d58f4d37d8c7b535021ff18d57861 has broken building android/viewer. | 21:50.41 |
| Robin_Watts | fredross-perry: 2 commits on robin/master, 1 of which fixes that. Sorry. | 23:15.19 |
| fredross-perry | s'ok. I made a commit that fixes that as well. What will happen when we push? | 23:15.42 |
| Robin_Watts | fredross-perry: When we push, nothing. | 23:16.58 |
| | When we pull --rebase before we push, we'll get a conflict. | 23:17.13 |
| | and whoever is second can do git rebase --skip and it'll just miss our patch out and keep the one that is in golden. | 23:17.38 |
| fredross-perry | my commit has one other thing in it that's necessary - another API change. (pdf_widget_get_type = pdf_widget_type). | 23:19.14 |
| | Can we have a moratorium on API changes> | 23:19.25 |
| Robin_Watts | fredross-perry: Sure, once we get the API right. | 23:19.57 |
| fredross-perry | ;-) | 23:20.16 |
| alexcher | I have been bitten by 2 GS bugs in a row (see the tracker). What's the current status of bug hunt and bug bounty program? | 23:21.35 |
| Robin_Watts | alexcher: Hey Alex. | 23:23.37 |
| | The bug bounty program is still in effect. | 23:23.49 |
| | and we're still bug fixing etc. | 23:24.21 |
| alexcher | But few bugs has been marked for bounty recently. Fuzzing, memcmp(), and my latest SEGV in tiffsep seem to be good candidates. | 23:27.45 |
| | memcpy() | 23:28.59 |
| Robin_Watts | If you think you've found good candidates, prod henry. | 23:29.40 |
| alexcher | OK | 23:31.08 |
| | Forward 1 day (to 2016/07/15)>>> | |
IRC Logs