| | <<<Back 1 day (to 2015/12/13) | 20151214 |
| tor8 | Robin_Watts: you forgot to add jni.vcproj to the jni2 branch | 10:50.54 |
| Robin_Watts | tor8: oops. Ta. | 10:55.40 |
| tor8 | Robin_Watts: I also see that you've started toying with your stroke font idea. | 10:56.20 |
| | have you looked at MetaFont at all? might have some ideas worth cribbing. | 10:56.32 |
| Robin_Watts | tor8: That branch is just me fiddling myself an app that can display glyphs/design boxes etc. Nothing useful yet, except the bap.txt file :) | 10:57.12 |
| tor8 | I only looked at the bap.txt file | 10:57.28 |
| Robin_Watts | I was on a flight with no wifi when I did that. Will look at metafont. | 10:58.55 |
| tor8 | it might also be worth talking with sebras about cjk font structure | 10:59.02 |
| | how radicals etc are done | 10:59.11 |
| | for korean, 99% of the glyphs are simple 2 or 3-component paste-jobs | 10:59.47 |
| | which could probably be special coded to take even less place | 11:00.05 |
| | so as not to even bother having the individual glyphs in the font table, just the components and the code could synthesize the positions | 11:00.25 |
| | each korean character is a syllable, composed of two to four "jamos" (sounds, think consonants and vowels) in a specific pattern | 11:01.47 |
| | either: vowel+consonan, or consonant+vowel/consonant, or CV/CC. | 11:02.33 |
| | each subcomponent has two or three possible shapes depending on whether it's in a 2-piece (where they are taller) and initial or final position | 11:03.05 |
| | so about 100 different shapes, which can be algorithmically positioned to create the 6000 or so characters | 11:03.36 |
| | paste that into bap.txt and forget about it for now :) | 11:04.01 |
| Robin_Watts | The idea of having scaffold lines defined, and then bending components to fit within different scaffold pairs is exactly for that. | 11:14.30 |
| | tor8: How would you feel about us having a void * ctx->user field? | 13:49.02 |
| | Would be set to NULL initially (and copied on fz_context_clone), but it would be somewhere for callers to stash some private information. | 13:49.52 |
| | It would be useful for me in the mupdf JNI stuff. | 13:54.26 |
| | I can probably work without it, but it'd be a lot simpler with it. | 13:54.41 |
| tor8 | Robin_Watts: I went the opposite way for MuJS; I stow the fz_context in the 'user' private state instead | 13:57.08 |
| | but I can see how it would be handy to be able to associate a void* with the fz_context | 13:57.41 |
| | so go ahead | 13:57.44 |
| Robin_Watts | Ta. | 13:58.00 |
| tor8 | void fz_set_user_context(ctx, void *user); void *fz_user_context(ctx); or something like that? | 13:58.25 |
| Robin_Watts | tor8: Could do, yeah. | 14:08.40 |
| | tor8: First 4 commits on robin/jni2 are good to go to golden, I reckon. | 14:31.10 |
| | actually, hold off on that. | 14:34.53 |
| tor8 | Robin_Watts: I don't quite understand the reasoning behind the pointer_cast static inline functions | 14:35.34 |
| Robin_Watts | tor8: I'm just tweaking that commit now. | 14:35.50 |
| | I have to stash native pointers in java vars. For safety, I've been (trying to) use java longs, which are 64bits. | 14:36.25 |
| | But that means it complains that I'm taking a 32bit pointer into a 64bit int and back again. | 14:36.47 |
| | I was hiding the nasty casting inside 2 functions so that I get 2 warnings rather than lots. | 14:37.19 |
| | but I've got a way to avoid the warnings entirely now. Just updating that commit. | 14:37.33 |
| tor8 | you've added jni.vcproj to the wrong commit | 14:37.56 |
| | fz_clone_path has these ugly /*@fallthrough@*/ comments, I'd much rather you dropped the '@' signs | 14:38.33 |
| | just "/* fallthrough */" is good enough for me | 14:38.43 |
| Robin_Watts | /*@fallthrough@*/ is what doxygen and various lints use. | 14:39.40 |
| | or so I thought, but googling doesn't show that up. | 14:40.56 |
| | I'll revert to the simpler form. | 14:41.02 |
| tor8 | I think most reasonable lints will detect the simpler form as wel | 14:41.54 |
| | l | 14:41.55 |
| Robin_Watts | tor8: OK, fixed versions online. | 14:49.12 |
| tor8 | Robin_Watts: okay, LGTM; but I haven't studied the actual bindings yet | 14:57.13 |
| | I expect we will reimplement the matrix math in Java rather than bind it using JNI | 14:58.20 |
| | in Document.java: the page array (mPages) and getPage() functions, should we not just expose a raw loadPage call? | 15:01.51 |
| Robin_Watts | tor8: The danger with that is that people might call loadPage(1) multiple times and we'd end up holding the same page in memory several times. | 15:31.06 |
| tor8 | Robin_Watts: exactly like with the C interface... | 15:38.01 |
| Robin_Watts | tor8: Yes. But java programmers expect a bit more simplicity I think. | 15:38.50 |
| tor8 | at this level of interface though? | 15:39.31 |
| Robin_Watts | especially because lots of them won't be used to calling 'destroy' etc to get rid of pages. | 15:39.54 |
| tor8 | the garbage collector finalizer should take care of that | 15:40.16 |
| Robin_Watts | tor8: Right, but that often doesn't call as soon as you'd like. | 15:40.34 |
| tor8 | Robin_Watts: and with the mPages array, it will never get called | 15:41.43 |
| Robin_Watts | indeed. | 15:42.03 |
| | Ok, let that sit with me for a bit. | 15:42.33 |
| tor8 | Robin_Watts: so if you call Document.getPage twice, then page.destroy() once, then Document.getPage again | 15:42.42 |
| Robin_Watts | You'll get the same java Page object every time. | 15:43.06 |
| tor8 | you'll have two pages in memory, one dangling and eventually garbage collected and one that won't due to sitting in the mPages cache | 15:43.10 |
| | page.destroy() will call Document.destroyPage which nulls the mPages entry | 15:43.30 |
| | so the third call will get another fz_page | 15:44.05 |
| Robin_Watts | tor8: yeah. | 15:44.27 |
| | You may be right. | 15:44.33 |
| tor8 | less magic hidden stuff is probably the best way to approach the JNI layer | 15:44.56 |
| | the Java classes we build on top for the application level stuff can add the smarts and ease-of-use for stackoverflow programmers | 15:45.55 |
| | did you write some code generation tool for generating the Java and JNI code? | 15:46.38 |
| Robin_Watts | The JNI layer is the mupdf_native.c | 15:47.01 |
| | The java layers built on top of that are com/artifex/mupdf/fitz/blah.java | 15:47.21 |
| | No. all hand written. | 15:47.40 |
| | I'm really not sure an automated tool would work. | 15:47.52 |
| tor8 | the com/artifex/mupdf/fitz/blah.java are just the stuff needed to hook the mupdf_native.c into actual classes, with some glue code for initialization and wrap/unwrap the pointer, as I understand it | 15:48.55 |
| | I remember using SWIG ten+ years ago | 15:49.33 |
| | for generating Python bindings | 15:49.47 |
| | our code is probably too odd to wrap automatically with that though | 15:50.12 |
| Robin_Watts | tor8: The blah.java classes contain magic to cope with java threads and contexts etc. | 15:50.36 |
| | Oh, bollocks. | 15:54.39 |
| | The fz_text and fz_stext changes have broken my code. | 15:55.05 |
| mvrhel_laptop | hi tor8: so I have a quick question. For the flags entry in font descriptor dictionary, the only one that I think I might be able to know to set (or not set) based upon what I can get out of Freetype is the fixed pitch and the symbolic/nonsymbolic. The others seem like they would require quite a bit of work to figure out if they should be set | 16:08.35 |
| | e.g. serif, script, italic, | 16:09.08 |
| Robin_Watts | Ok, tor8: Updated commits on robin:jni2 | 16:24.28 |
| | 7/9 of them are ready to go. | 16:24.53 |
| | The top 2 are still works in progress. | 16:25.02 |
| chrisl | mvrhel_laptop: other than symbolic/non-symbolic, the flags are only really used for finding a substitute font. As you are embedding the font, you can ignore them - for now, at least | 16:30.59 |
| mvrhel_laptop | chrisl: ok thanks. I was thinking that was the case | 16:32.16 |
| chrisl | mvrhel_laptop: once you head down trying to set them, it ends up in a morass of heuristics | 16:33.19 |
| mvrhel_laptop | right | 16:33.33 |
| | so the decision for if a font has the symbol flag set or not is that if it has a single glyph outside the Character set specified in D.1 then it is considered a symbol. tor8: how do you want me to handle this? I guess I need to have a table with all those names and go through the glyph names exiting if I find one that is not in the table (indicating a symbol font) or if I go through all... | 17:06.38 |
| | ...the glyphs then it will be set as Nonsymbolic. Or since we do have the font embedded anyway I can just set Nonsymbolic and keep moving forward | 17:06.39 |
| | and we can return to this mess later | 17:07.08 |
| tor8 | mvrhel_laptop: the only significant flag is the nonsymbolic one, which changes how encoding tables are done | 17:07.44 |
| | for Identity encoded fonts, I think it's irrelevant | 17:08.01 |
| mvrhel_laptop | ok | 17:08.06 |
| tor8 | sorry, I meant that the symbolic flag is the significant one | 17:08.35 |
| | for the WinAnsi encoded fonts, I think you can just leave both symbolic and nonsymbolic unset | 17:08.39 |
| | the symbolic flag changes how the "default" built-in font encoding is selected | 17:10.09 |
| | when using Identity encodings, the default built-in font encoding is ignored | 17:10.51 |
| | when using WinAnsi encodings, the default built-in font encoding is used, and then you just want to make sure that "symbolic" is not set | 17:11.15 |
| mvrhel_laptop | ok | 17:11.25 |
| chrisl | If it's being loaded as a CIDFont, it doesn't have an encoding | 17:11.36 |
| tor8 | chrisl: true. I was thinking mostly of simple fonts. | 17:11.55 |
| | chrisl: the way of creating fonts that I discussed with michael was to do it in two different ways. | 17:12.30 |
| | for the 'mutool create' tool, create a simple font from a truetype using WinAnsi encodings | 17:12.56 |
| | for the internal 'pdfwrite'-like device in mupdf, create a CID font using an Identity encoding | 17:13.16 |
| chrisl | Using "encoding" with CIDFonts is confusing..... | 17:14.17 |
| tor8 | chrisl: how so? A PDF font object has a /Encoding entry... | 17:16.28 |
| | also for the Type0 cid fonts | 17:16.41 |
| | now, a CIDFont file has no encoding, if that's what you mean? | 17:17.21 |
| chrisl | Yes, so the Encoding in the font object is *not* the built-in encoding of the (CID)font | 17:18.40 |
| mvrhel_laptop | yeah! I have the font embedding working | 17:41.51 |
| chrisl | Nice! | 17:42.08 |
| mvrhel_laptop | need to clean up a few things | 17:43.03 |
| | and work on making sure we reuse our resources | 17:43.36 |
| | if we reuse the same image or fonts | 17:43.57 |
| Robin_Watts | mvrhel_laptop: Nice. That looked really hairy. | 17:45.18 |
| mvrhel_laptop | so having the flags all zero does elicit a complete from acrobat | 17:47.49 |
| | complaint | 17:47.58 |
| | no complete | 17:48.03 |
| | this is just doing the simple font. still need to do the CID font with Identity encoding | 17:48.59 |
| fredross-perry | Is it OK to push my two muPDF changes from Friday? | 17:49.03 |
| Robin_Watts | Did someone review them? | 17:50.07 |
| chrisl | mvrhel_laptop: you have to set either the symbolic or non-symbolic flag | 17:50.21 |
| fredross-perry | Not that I am aware of. Thatâs why I am asking. | 17:50.24 |
| mvrhel_laptop | chrisl: right | 17:50.32 |
| chrisl | Goodness knows why they did that! | 17:50.45 |
| fredross-perry | Also, I put them in a branch based on 1.8, so Iâll build that. | 17:50.48 |
| Robin_Watts | fredross-perry: The magic constants one is certainly OK, I reckon. | 17:51.28 |
| fredross-perry | thatâs not mine. | 17:51.55 |
| Robin_Watts | and the ios one looks reasonable to me (who doesn't really understand ios at all) | 17:51.58 |
| | oh, right, I only see 1 commit on master. | 17:52.39 |
| | and another one on fred/release_1.8 | 17:52.50 |
| | and they are actually identical. | 17:53.21 |
| fredross-perry | robin, if I âgit push golden release_1.8â, will I get just the branch, as I hope? | 17:53.26 |
| | yes I did it once last week and again today on a branch. | 17:53.40 |
| Robin_Watts | That will push the release_1.8 branch to golden, yes. | 17:53.51 |
| | go for it. | 17:54.04 |
| fredross-perry | done. Now I can adjust the build procedureâs mupdf submodule to point to this branch. | 17:56.36 |
| Robin_Watts | tor8: Ah, I just remembered something. | 18:17.48 |
| | If a Page is ever unreferenced, (or destroy()ed) it calls Document.destroyPage() and that removes it. | 18:18.23 |
| | so we can't get into the situation you were talking about. | 18:18.32 |
| | And Pages have to keep a reference to the Document (because fz_page's don't) | 18:21.09 |
| fredross-perry | Looks like we need to disable bitcode for the iOS release. The Crashlytics code weâre using does not have it, and a bitcode build requires all object code to have it. | 18:21.23 |
| Robin_Watts | fredross-perry: Is there updated crashlytics code? | 18:21.52 |
| fredross-perry | I can look. But there was some dsicussion (disagreement) about whether to ship a bitcode build anyway. | 18:22.30 |
| Robin_Watts | fredross-perry: yeah. It mentioned ios so I turned off... | 18:23.13 |
| fredross-perry | ;-) | 18:23.26 |
| tor8 | Robin_Watts: fz_pages now keep a fz_document reference | 18:32.41 |
| | I made that change a while back | 18:32.45 |
| | how does unreferencing a Page ever call Document.destroyPage? | 18:33.16 |
| | if you call Page.destroy() I see where it calls Document.destroyPage | 18:34.19 |
| Robin_Watts | oh, because Page.finalizer is never called, it can never call Page. destroy. All. | 18:36.42 |
| | s/All/ass/ | 18:36.45 |
| | tor8: Where does fz_page keep an fz_doc reference ? | 18:37.56 |
| tor8 | Robin_Watts: in the subclasses that need it (such as pdf_page) | 18:38.37 |
| | to reduce the amount of type-casting required | 18:38.58 |
| Robin_Watts | tor8: Ah, that's no good to me, I think. | 18:39.20 |
| tor8 | I changed all the page-related functions to not require a second document argument | 18:39.29 |
| | I have not got around to doing the same for fz_annots | 18:39.45 |
| | if you drop the idea of caching loaded pages in Document.getPage I don't see anywhere you would need to get the document from the page | 18:40.30 |
| | what you might want instead is a global page cache which has weak references if such a thing exists in java | 18:41.21 |
| Robin_Watts | tor8: No such thing, AIUI. | 18:42.11 |
| tor8 | huh, imagine my surprise when I googled and found http://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html | 18:42.25 |
| Robin_Watts | OK, you're right. I can't see any immediate reason why I need fz_doc from fz_page. | 18:42.28 |
| tor8 | java has come a long way since I used it back in the 90's... | 18:42.38 |
| | still, that might not exist in android's java version | 18:42.57 |
| | are they still at java 6? | 18:43.04 |
| Robin_Watts | Is that defined in.. yeah. | 18:43.06 |
| | no, they are at 1.7. | 18:43.13 |
| | and sometimes 1.8 works. | 18:43.28 |
| tor8 | https://developer.android.com/reference/java/lang/ref/WeakReference.html would suggest it works | 18:43.35 |
| Robin_Watts | ok, can look at that at some point. | 18:46.15 |
| tor8 | for now though, I suggest just going with a raw loadPage binding. | 18:46.43 |
| Robin_Watts | hmm. Possibly rather than stripping out the current document mPages[] stuff, I should convert that to weakrefs. | 18:46.55 |
| tor8 | yeah, that would work too. | 18:47.22 |
| | without burdening the user with remembering to call page.destroy() | 18:48.00 |
| Robin_Watts | I'd leave page.destroy() in there for the conscientious. | 18:48.25 |
| tor8 | Robin_Watts: that's not going to work as you intend it though, it'll just force it to be cleared from the mPages not actually unload the page. and leave you with a potentially broken Page if it's referenced anywhere else other than the page.destroy() caller | 18:49.29 |
| | s/. and/or/ | 18:49.39 |
| Robin_Watts | Urm... it leaves the page destroyed. | 18:57.55 |
| | any attempt to use the Page afterwards will fail. I check for page == NULL on entry to each native call. | 18:58.18 |
| | If you call Page.destroy() then you must always call Page.destroy() | 18:59.01 |
| | It should never leave us with a 'broken' page. | 19:00.27 |
| | If a caller calls Page.getPage twice, and then destroy just once, the other Page reference he is holding becomes useless. | 19:00.50 |
| | This is exactly the same as Bitmap.recycle() in android. | 19:01.01 |
| | I think I'm going to strip it back to being as simple as possible. | 19:12.25 |
| | and put the weakrefs in the app. | 19:12.34 |
| | tor8: Did you have an opinion on those 7 commits? | 19:15.55 |
| mvrhel_laptop | tor8, Robin_Watts: So when I drop a pdf_object1 that is a reference to another object (say object 2), if this is the only reference to object 2 (and the object 2s ref count is 1), when I drop object 1 (with pdf_drop_obj) it is looking to me like I would leak object 2. Am I mistaken or missing something | 20:00.18 |
| Robin_Watts | mvrhel_laptop: hi | 20:02.18 |
| | if you pdf_drop_object(obj1), that will pdf_drop_obj() all the subobjects it has. | 20:02.59 |
| | so if that's the last reference to obj2, then obj2 will be destroyed too. | 20:03.15 |
| mvrhel_laptop | Yes, I see that looks like it is true if the type is PDF_ARRAY or PDF_DICT | 20:03.50 |
| | but what if it is PDF_INDIRECT | 20:04.44 |
| Robin_Watts | A pdf_indirect doesn't contain a pointer to an object. It just contains the number and the generation. | 20:05.08 |
| | As we load objects by number and generation, they are linked into the pdf_xref structure. | 20:05.33 |
| | Hence if you drop an indirect reference, there are no (real) subobjects to drop. | 20:06.03 |
| | Certainly nothing is leaked because the subobject is still referred to by the pdf_xref. | 20:06.25 |
| mvrhel_laptop | ah. I see. So when I do pdf_new_ref, the rc is from it being stored in the xref struct | 20:06.33 |
| | yes | 20:06.39 |
| | ok. Sorry I should have realized that | 20:06.50 |
| Robin_Watts | No worries. It's new ground. | 20:07.00 |
| mvrhel_laptop | I am paranoid of leaks... | 20:07.12 |
| Robin_Watts | mvrhel_laptop: Just build with memento and run. | 20:07.27 |
| mvrhel_laptop | yes. I will do that soon | 20:07.33 |
| Robin_Watts | It'll tell you if it leaks, and where from. | 20:07.34 |
| mvrhel_laptop | thanks Robin_Watts | 20:07.41 |
| Robin_Watts | no worrie.s | 20:07.44 |
| mvrhel_laptop | bbiab. lunch time | 20:23.39 |
| tor8 | mvrhel_laptop: looks like Robin_Watts answered your question :) | 20:25.32 |
| | Robin_Watts: the first 7 (up to but not including JNI bindings) LGTM | 20:25.56 |
| | I wonder if we should put the JNI stuff in platform/java/ and make sure it works on desktop java as well. | 20:26.38 |
| | would make it easier to test stuff for me | 20:26.46 |
| Robin_Watts | tor8: It is intended to work with desktop java too. | 21:01.26 |
| | The native stuff has AwtDrawDevice for that very reason. | 21:01.49 |
| | Forward 1 day (to 2015/12/15)>>> | |
IRC Logs