| | <<<Back 1 day (to 2018/04/05) | 20180406 |
| sebras | Robin_Watts: after a quick review: LGTM. | 01:47.31 |
| | Robin_Watts: I can't fault it. | 01:47.37 |
| Robin_Watts | tor8: you here? | 11:11.45 |
| | and paulgardiner. | 11:11.53 |
| tor8 | Robin_Watts: I'm around | 11:13.14 |
| Robin_Watts | So, there was an email to support from Cody. | 11:13.29 |
| | As far as I can see PDF form fields can point to PDF annotations of type 'widget'. | 11:13.52 |
| | but nothing in the widget annotation say what type of form field they are for. | 11:14.07 |
| | So the simplest thing I can think of for Cody to be able to identify form fields is to: | 11:14.46 |
| | 1) have a pdf_annot_obj that returns annot->obj so he can get the PDF object that corresponds to a given annotation. | 11:15.05 |
| | 2) To get Root/AcroForm/Fields, and to walk that looking for references to that object, and from those he can find the type. | 11:15.37 |
| | Does that seem correct to you? | 11:15.44 |
| tor8 | Robin_Watts: bah. I'm planning to separate widgets into their own struct (so they won't be pdf_annot anymore) | 11:15.52 |
| Robin_Watts | OK. | 11:16.02 |
| | So, do I say "this is how you'd have to do it today, but we are working on a streamlined process in future"? | 11:16.26 |
| paulgardiner | Maybe I'm misunderstanding, but there's function pdf_widget_type | 11:16.42 |
| tor8 | paulgardiner: it's a typedef of the same underlying type | 11:16.59 |
| | the code assumes they are interchangeable | 11:17.05 |
| | paulgardiner: sorry, I misunderstood your statement. | 11:17.33 |
| | you're right. there is a pdf_widget_type() call he can use | 11:17.41 |
| Robin_Watts | Oh, brilliant! | 11:17.50 |
| | I'll write that in a reply. Thanks. | 11:18.30 |
| tor8 | Robin_Watts: you might want to point out that pdf_widget and pdf_annot are the same type and interchangeable today, but warn him that things may change in a future release | 11:18.47 |
| | as we streamline these sorts of things | 11:18.57 |
| Robin_Watts | I won't tell him they are interchangable. | 11:19.05 |
| tor8 | I plan on adding a separate enumerator for widgets, separate from annotations | 11:19.29 |
| | but that's not there yet | 11:19.32 |
| | been distracted by build issues | 11:19.39 |
| paulgardiner | I thought there was already a separate enumerator | 11:19.52 |
| | Maybe I just intended to add one and never did | 11:20.31 |
| Robin_Watts | There is a separate enumerator. | 11:21.20 |
| | pdf_first_widget, pdf_next_widget | 11:21.38 |
| paulgardiner | ah yes | 11:22.35 |
| tor8 | paulgardiner: see, I'm still fuzzy about how this works :) | 11:23.27 |
| paulgardiner | You and me both. :-) | 11:23.39 |
| tor8 | paulgardiner: I expect to make pdf_first_annot filter out and not return widgets then | 11:23.54 |
| Robin_Watts | Ok, I've replied. Thanks guys. | 11:24.13 |
| tor8 | but he should be able to use the pdf_first_widget enumerator with the pdf_widget_type functions without much disturbance if I go around and change things later | 11:24.32 |
| paulgardiner | yeah, just best not cast back and forth between annotations and widgets | 11:25.04 |
| sebras | tor8: still here? | 14:08.37 |
| tor8 | sebras: yes. | 14:08.51 |
| sebras | tor8: how about a quick review of sebras/master? | 14:08.54 |
| | tor8: you asked for the gamma interface, and you've got it. :) | 14:09.10 |
| tor8 | sebras: LGTM :) | 14:09.24 |
| sebras | tor8: merged. | 14:09.53 |
| | tor8: I don't think you and robin discussed the PDF_NAME_X -> PDF_NAME(X) change. is that really necessary? | 14:10.41 |
| | is there a benefit? | 14:10.47 |
| Robin_Watts | The "benefit" is that we can remove the namedump code. | 14:11.16 |
| sebras | Robin_Watts: that's not what I asked. | 14:11.33 |
| Robin_Watts | If we want the "benefit" it's necessary. | 14:11.52 |
| sebras | Robin_Watts: I asked whether there is any benefit in haveing PDF_NAME() as a macro taking an argument. | 14:12.07 |
| Robin_Watts | sebras: The alternative being? | 14:12.25 |
| | What was previously PDF_NAME_Fred would now have to be ((pdf_obj *)PDF_NAME_Fred) | 14:13.07 |
| | (or ((pdf_obj *)PDF_ENUM_Fred) or something) | 14:13.46 |
| | or am I missing something? | 14:14.01 |
| tor8 | sebras: the macro taking an argument is necessary to do it all with the C preprocessor | 14:16.45 |
| | since you can't define new macros inside macros | 14:16.52 |
| sebras | tor8: that's what I was looking for. ok. | 14:17.09 |
| | tor8: in that case that patch looks ok to me. | 14:17.25 |
| tor8 | I think it's worth the slight hit in aesthetics to be able to avoid yet one more build complication | 14:17.38 |
| Robin_Watts | I am inclined to agree. | 14:17.47 |
| tor8 | especially if we're entertaining thoughts about using cmake | 14:17.51 |
| Robin_Watts | much as it pains me. | 14:17.57 |
| | oh, god, no, not cmake. | 14:18.04 |
| | premake, maybe. | 14:18.08 |
| sebras | Robin_Watts: hey, we can use curl to fetch the font files from mupdf.com on the fly when mupdf starts! ;) | 14:18.23 |
| tor8 | Robin_Watts: okay. what's made you change your mind about cmake? | 14:18.24 |
| Robin_Watts | tor8: The fact that the generated makefiles aren't portable. | 14:18.43 |
| sebras | are the premake files portable? i.e. do the use absolute paths? | 14:19.05 |
| tor8 | right, and you want the result to be checked into the git so clients don't need the cmake/premake/whatever tool? | 14:19.06 |
| Robin_Watts | Yes. | 14:19.10 |
| tor8 | sebras: the premake files are portable | 14:19.14 |
| sebras | perhaps cmake can be forced to not generate absolute paths..? | 14:19.24 |
| tor8 | sebras: cmake is a combined autoconf+automake deal. it does per-system configuration crap that it puts into the build files it generates | 14:19.56 |
| sebras | tor8: I think checking in the generated files is a good idea too. | 14:20.00 |
| tor8 | sebras: I have a cleaned up GNU makefile system in the works | 14:20.18 |
| | sebras: on the tip of tor/master if you want to look | 14:21.25 |
| | sebras: invoke with "make -f nb/Makefile" | 14:21.34 |
| Robin_Watts | If we can have a single thing that we use to generate make/vs/xcode/android etc things from, then that's got to be a good idea. | 14:23.54 |
| tor8 | I've learned a bit more about make since writing the original Makefile | 14:24.00 |
| | these new ones are *much* simpler | 14:24.09 |
| | and do the same stuff, and get dependencies right | 14:24.19 |
| | and should be much easier to edit | 14:24.28 |
| Robin_Watts | tor8: Right, but no amount of simplification solves the "but I want a VS2010 version" problem. | 14:24.45 |
| tor8 | well, they don't support system libraries for our third party dependencies... but we don't want to support that anyway | 14:24.49 |
| | Robin_Watts: yeah. this has let me think about what we actually need though. it looks like premake5 is the best choice for making VS2010 etc projects. | 14:25.41 |
| | the biggest headache is what to do about android and ios | 14:25.49 |
| | but I think just maintaiing the current Android.mk is easy enough (since it uses wildcards, etc) | 14:26.43 |
| Robin_Watts | Yes. This needs someone to devote a few days to it to figure out what is possible. | 14:26.50 |
| | but that should happen AFTER the release. | 14:26.59 |
| | (If I get this stuff done, I'll look into it, but I'm a way away yet) | 14:27.20 |
| tor8 | yes. none of this build stuff will happen before the release. | 14:27.30 |
| | I think we should just tag waht we have today and call it a day. | 14:27.38 |
| | we need to write a CHANGES file, but I think that's all we really need | 14:27.54 |
| | I don't want to update freetype and harfbuzz yet. freetype has a lot of diffs I need to look through | 14:28.10 |
| | and harfbuzz has stopped working on vs2005 | 14:28.18 |
| Robin_Watts | seems reasonable. | 14:28.30 |
| kens | There's a new FT due imminently too tor8 | 14:28.34 |
| tor8 | kens: yeah. so I may just wait for that. | 14:28.45 |
| Robin_Watts | I have nothing urgent to get in for the relase. | 14:28.47 |
| tor8 | kens: I noticed some reversions in how freetype handles hinting that broke our dynalab workaround... | 14:29.09 |
| kens | Oh really ? Do we not have any examples in the test sutie ? | 14:29.27 |
| tor8 | kens: I either had to feed it the HINT_THIS_FOR_MONO or force set the face_flags |= TRICKY | 14:29.48 |
| kens | I don't think Chrisl had any problems with the current reelase. Of course GS uses FreeType very differently to MuPDF | 14:29.52 |
| tor8 | kens: we do, bug 691997.pdf for one | 14:30.18 |
| kens | Hmm le tme quickly look at that | 14:30.31 |
| tor8 | but I think we drive them differently enough that we probably don't trigger the same issues | 14:30.38 |
| kens | (though chrisl has not updated GS with a newer FT yet) | 14:30.42 |
| tor8 | that one has a subsetted dynalab font that freetype's own 'tricky' detection doesn't trigger on | 14:30.58 |
| kens | Hmm, I see | 14:31.09 |
| tor8 | kens: that one stopped working in 2.7 already | 14:31.11 |
| chrisl | I thought Freetype had its own tricky font recognition | 14:31.19 |
| tor8 | so I think you probably have it working, it just tripped up mupdf | 14:31.23 |
| kens | Oh well we were using 2.7 before, so let me try the file | 14:31.28 |
| tor8 | chrisl: it does, but it doesn't always work... I do a separate font name check to see if it starts with "DL" | 14:31.55 |
| chrisl | I don't think we do that | 14:32.20 |
| tor8 | chrisl: gs gets it right though, so I don't think you need to worry | 14:33.15 |
| kens | Oops, I'd resynched my code and frogotten to build GS, just a second | 14:33.19 |
| | Oh, well in that case I guess we're OK :-) | 14:33.30 |
| chrisl | Oh, we enable TTF hinting by default | 14:33.59 |
| kens | Ah | 14:34.07 |
| tor8 | ah yes, I ask for unhinted by default | 14:34.32 |
| | but tried to ask for hinting, but it didn't pick the truetype hinting unless I asked for _MONO in more recent freetypes | 14:34.54 |
| sebras | tor8: for android we have to go for cmake in the end anyway. | 14:35.07 |
| | tor8: but that's my headache. | 14:35.14 |
| chrisl | tor8: normal hinting doesn't make much sense for anti-aliased output | 14:35.40 |
| sebras | tor8: perhaps the correct way forward is to adopt the premake-android plugin..? | 14:35.55 |
| tor8 | if we can make the thirdparty libraries build without needing to faff about with stdint.h and HAVE_STDINT_H and HAVE_INTTYPES_H and a bazillion other idiotic defines we'd be in much better shape | 14:36.00 |
| sebras | as in taking over ownership. | 14:36.04 |
| tor8 | to just have a 'here's the list of files to build. have at it.' | 14:36.08 |
| Robin_Watts | tor8: Can you review the commit on robin/master please? | 14:55.47 |
| | The store fix one. | 14:55.52 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=46407fb9c49a6c4a30dbdf50347bbe60c3f598fb | 14:56.15 |
| sebras | Robin_Watts: hav eyou changed that one since yesterday? | 15:07.48 |
| Robin_Watts | No. Did it get reviewed yesterday? | 15:08.15 |
| | sebras: Apologies. I missed your comment. | 15:08.35 |
| sebras | Robin_Watts: the only thing in that commit that I was thinking about while looking through it is that item->prev is stale for the objects in the to_be_freed list. | 15:08.39 |
| | Robin_Watts: but then again that doesn't matter i tseems. | 15:08.48 |
| | Robin_Watts: that's ok. I also miss the logs. :) | 15:09.04 |
| Robin_Watts | Yeah, we don't use the prev pointer in to_be_freed. | 15:09.06 |
| | sebras: Thanks for that. | 15:09.23 |
| sebras | Robin_Watts: sure. :) | 15:09.47 |
| Robin_Watts | fredross-perry: Fix pushed. | 15:10.25 |
| fredross-perry | lovely, thanks! | 15:10.38 |
| | Is there anything else in the offing I should wait for before updating? | 15:18.42 |
| | Forward 1 day (to 2018/04/07)>>> | |
Log of #mupdf at irc.freenode.net.