| | <<<Back 1 day (to 2016/09/06) | 20160907 |
| sebras | tor8: I thinks I have adressed your concerns now, and there is a whole slew of new patches ontop of the JNI-ones over at sebras/master | 02:31.14 |
| | tor8: hi! | 11:16.40 |
| tor8 | sebras: hi. | 11:29.11 |
| sebras | tor8: do you have time to take a last look at the comimts? | 11:30.00 |
| tor8 | sebras: looked through a diff from yesterdays commits to todays. most of it looking good, but I'm not convinced of how fz_set_device_hints works | 11:32.37 |
| | and I'm sure Robin will flame you for using strings to set the heuristic hints in the constructor :) | 11:33.01 |
| Robin_Watts | tor8: I'm not a huge fan of that, but it's what we've been standardising on, right? | 11:33.38 |
| tor8 | Robin_Watts: for the device flags, we have, yes. it's more flexible when different devices accept so many different options. | 11:34.07 |
| sebras | tor8: yes, but we did discuss that way back when and I think we came to the conclusion that strings are super flexible and if we don't call those functions _too_ often then it is... acceptable. | 11:34.20 |
| tor8 | and I think it makes rough sense to have a list of heuristics be a string of options | 11:34.54 |
| | though for the stext heuristics I don't see much use beyond a set of booleans to toggle passes on or off | 11:35.44 |
| | and likewise for the device hints | 11:35.48 |
| | so there I think it would also make equal sense to just keep them as a bit flag | 11:36.01 |
| sebras | tor8: true, but if we use strings we don't need to change the interface later on if we have more than 32 flags. | 11:36.19 |
| tor8 | 31, don't want to get into signedness issues :) | 11:36.42 |
| | also: ick! 31 boolean flags ... I hope we *never* end up with that many | 11:37.02 |
| sebras | tor8: well, if I'd kept the stext flags global then we'd have eight! | 11:37.42 |
| | tor8: ok, so I'll scrap the fz_set_device_hints() commit altogether and rework the stext-stuff to use bitflags instead? | 11:38.08 |
| | Robin_Watts: did you lend tor8 your bad irc connection? ;) | 11:42.08 |
| tor8 | sebras: apparently I got disconnected... | 11:48.39 |
| | sebras: fz_set_device_hints implementation is 'broken' ... it with a string like "ignore-image=no" it will do the unexpected thing | 11:48.45 |
| | sebras: have you tried building this on windows? I'm not sure about #include <sys/stat.h> | 11:48.48 |
| | fz_open_archive_entry uses singular 'entry' in the error message where the other functions use plural | 11:48.57 |
| | do we really need fz_lookup_archive_metadata? | 11:49.01 |
| | read_zip_dir_imp, why not zip->count++ *after* setting the name, offset, csize, usize so you don't need zip->count-1 in all the array accesses | 11:49.06 |
| | sebras: yes, I think that's better for now (scrap set_device_hints and use bitflags for stext heuristics) | 11:49.33 |
| sebras | tor8: no I have no windows machine at all. I asked you and robin for help on that one. | 11:49.56 |
| tor8 | sebras: so, in the zip archive implementation, you load the zip directory of entries lazily on first access | 11:50.05 |
| | I think that may be misleading if the zip file is malformed, you won't get an error on opening the zip file but much later | 11:50.27 |
| | sebras: it was too long ago (over my vacation) so I forgot if we came to a conclusion | 11:50.54 |
| | the 'only regular files are supported' message, I assume that's for symlinks? what about directories? | 11:52.34 |
| | would it be useful to just ignore non-regular file entries in tar archives? | 11:52.56 |
| sebras | tor8: fz_lookup_archive_metadata() is currently only used to determine the format. I call it from cbz which has to have such a function because it is a fz_document | 11:55.04 |
| | tor8: but if we are happy with returning CBZ there then I can scrap fz_lookup_archive_metadata(). | 11:55.26 |
| tor8 | I'm happy to return "CBx" :) | 11:56.07 |
| | or it can poke directly at the fz_archive.format field | 11:56.39 |
| sebras | tor8: ok. can fix. | 11:57.09 |
| tor8 | or if you're squeamish about that sort of code, fz_archive_format() | 11:57.13 |
| | no need for the whole generic lookup_metadata, imo | 11:57.23 |
| sebras | tor8: fz_archive_format() is probably the cleanest. | 11:57.37 |
| tor8 | the JNI stuff LGTM. question is whether to squish or not. | 11:57.50 |
| | sebras: yes. | 11:57.57 |
| sebras | tor8: as long as each commit compiles and works then there is no real reason not squash them. | 11:58.29 |
| Robin_Watts | tor8: When writing some documentation the other day I noticed an inconsistency. | 11:58.47 |
| sebras | tor8: if we have to locate bugs later on I think having separate patches are nice. | 11:58.52 |
| tor8 | Robin_Watts: the unshare hack? | 11:59.00 |
| Robin_Watts | Yes. | 11:59.05 |
| tor8 | Robin_Watts: does fz_clone_path return an editable path? | 11:59.39 |
| Robin_Watts | tor8: yes. | 11:59.48 |
| sebras | tor8: re: lazy loading of entries.. even if read all entries immediately after opening the file there is nothing ensuring that those entries are still there when I want to access them (consider if the archive is really a directory) | 12:01.37 |
| | tor8: does it matter if we throw when fz_open_archive() is called or fz_count_archive_entries()? | 12:03.08 |
| tor8 | sebras: directories don't use an entries table to pre-load...? | 12:03.20 |
| sebras | tor8: fz_read_archive_entry() may fail later anyway if e.g. the flated data is corrupt. | 12:03.34 |
| tor8 | I'd prefer on fz_open_archive. XPS doesn't call fz_count_archive_entries | 12:03.39 |
| sebras | tor8: ok. I'll move it. :) | 12:04.02 |
| tor8 | sebras: yes, but that's a later error relating to the individual entry rather than the actual zip structure :) | 12:04.16 |
| | sebras: I make the same argument for tar archives | 12:04.55 |
| sebras | tor8: similar in how mupdf scans PDFs for structural errors when opening it and not suddently complaining about missing objects later on? >;) | 12:05.17 |
| | tor8: agreed. if I change unzip.c then untar.c should change accordingly! | 12:05.42 |
| | tor8: the tar typeflag can represent regular files, soft/hard links, char/blk device nodes, directories, fifo nodes, sparse files and multi-volume files. | 12:10.47 |
| | tor8: I opted to only implement the most simple case so far as I'm not sure whether we'd even end up using any of the others. | 12:11.18 |
| | tor8: I can be persuaded to ignore non supported entries in the same way we ignore files whose names does not fit the template are ignored in cbz. | 12:12.06 |
| tor8 | sebras: well, directories are entries in tar archives, I don't think we want to die on the presence of those? | 12:12.39 |
| | we could throw an error when trying to open a non-file entry, or pretend they don't exist | 12:13.13 |
| sebras | tor8: ok. | 12:14.10 |
| tor8 | cbz_create_page_list, if (arch) name = ...; then the line after uses 'name', maybe uninitialized | 12:14.31 |
| | same with 'count' a few lines above | 12:14.46 |
| | why are we even testing if (arch) there? | 12:15.42 |
| | a remnant from having separate directory/zip-archive code paths? | 12:15.58 |
| sebras | tor8: yes. | 12:16.27 |
| tor8 | sebras: from my reading sys/stat.h should be okay on windows too, but you may need to call _stat rather than stat | 12:20.42 |
| | if (!fz_is_directory(ctx, path)) | 12:21.41 |
| | fz_throw(ctx, FZ_ERROR_GENERIC, "'%s' is not a directory", path); | 12:21.41 |
| sebras | yes..? | 12:22.07 |
| tor8 | improved error message | 12:22.20 |
| sebras | oh. | 12:22.25 |
| | tor8: I chose the name heuristics to separate it from the hints in the parent interface. is that a good idea or a bad one? | 12:37.10 |
| | is options a better name? | 12:37.14 |
| tor8 | options is better, yes | 12:38.18 |
| sebras | tor8: because I'm out and about. do you mind pulling sebras-gh and taking a look? | 12:58.49 |
| | tor8: also I cannot git cluster from here. | 12:58.59 |
| | tor8: but it pdfrefs both natively and in java. | 12:59.16 |
| tor8 | sebras: typo "If this options is enabled" | 13:06.36 |
| | sebras: grammar "Mask of heuristic options to active." | 13:07.04 |
| | sebras: it's now impossible to create a stext device with both flags unset | 13:09.23 |
| | maybe we should invert the flag meanings, FZ_STEXT_KEEP_LIGATURES, FZ_STEXT_KEEP_WHITESPACE? | 13:10.05 |
| | hm, PRESERVE rather than KEEP | 13:10.21 |
| sebras | right. | 13:10.47 |
| tor8 | and ensure_xxx_entries can drop the count >= 0 test if we always call it | 13:11.18 |
| | and thus also drop the count = -1 assignment | 13:11.31 |
| | sebras: we probably ought to implement count/list for directory archives too; shouldn't be too complicated to add | 13:17.04 |
| | but it'll have to be #ifdef'd on windows, since I doubt opendir/readdir exist on win32 | 13:17.20 |
| | but that can be saved for later | 13:20.29 |
| sebras | tor8: so there we'd need to use FindFirstFile/FindNextFile. | 13:20.38 |
| tor8 | sebras: or include http://www.two-sdg.demon.co.uk/curbralan/code/dirent/dirent.html | 13:21.31 |
| sebras | tor8: which one is the count >= 0 test you referred to? | 13:22.43 |
| tor8 | sebras: nvm, that one is gone already. jsut the count = -1 before ensure_xx_entries (which probably should read load_xx_entries) | 13:23.39 |
| sebras | tor8: oh.. it was still there in zip but not in tar. :) | 13:23.57 |
| | tor8: oh, and you did notice that I snuck a fontdump patch in at the top of the stack? it originates from a complaint from coverity. | 13:25.24 |
| | tor8: I started looking through its complaints recently. | 13:25.38 |
| | tor8: it appears some a quite valid but a whol3e slew of them are due to exceptions. | 13:25.52 |
| | tor8: sebras-gh updated. | 13:26.03 |
| tor8 | sebras: yeah, I'm not impressed by coverity's confusions when it comes to our exception handling | 13:26.36 |
| | sebras: LGTM | 13:27.36 |
| sebras | tor8: I think we could teach it using a modelling file, but I don't know how to write one. | 13:30.26 |
| | tor8: alright. so I'll cluster it and once that has suceeded i'll push the lot. sounds alright? | 13:31.12 |
| tor8 | sebras: okay. | 13:32.33 |
| sebras | tor8: has the top patch on tor/master already gone in? | 13:35.57 |
| | oh.. it has, but not from your branch! :) | 13:36.55 |
| | tor8: ok, then I'll cherry-pick your annotation thingies and build on them next. cool. | 13:43.58 |
| | tor8: I'm off to write some mandarin characters now. thanks for all the help! :) | 13:44.23 |
| mvrhel_laptop | ray_laptop: To avoid confusion moving here. I would hope end of this week but maybe we should tell them early next week to be safe | 14:43.22 |
| ray_laptop | mvrhel_laptop: here we can't mention the customer name :-) | 14:44.15 |
| mvrhel_laptop | yes | 14:44.24 |
| ray_laptop | mvrhel_laptop: I'm adding float Matte[GS_CLIENT_COLOR_MAX_COMPONENTS] to gs_transparency_mask_params_t (and the gx_ variant) | 14:45.39 |
| mvrhel_laptop | ray_laptop: ok. I am working on the rendering side. Getting one odd effect that I am trying to track down. It may take a bit | 14:48.11 |
| | i.e. the day | 14:48.18 |
| ray_laptop | mvrhel_laptop: I assume that you are just fudging in a Matte array for now? | 14:49.09 |
| mvrhel_laptop | ray_laptop: yes exactly | 14:49.22 |
| | I am going to assume it will be in the pdf14_buf structure | 14:49.57 |
| ray_laptop | mvrhel_laptop: note that the image3x will not be used unless the device returns true for PreserveSMask (with the new logic) | 14:50.42 |
| sebras | tor8: argh, cluster push segfaults. :-( | 15:16.03 |
| | a missing fz_rethrow() in the archive-handling. | 15:27.08 |
| mvrhel_laptop | ray_laptop: ok I think I have the rendering part working. Let me check the big file real quick. I was just testing the small file | 15:39.46 |
| sebras | tor8: ok, my two zip and tar commits have been updated with a fz_rethrow() at the end of the fz_open_xxx_archive() function. | 15:39.48 |
| | tor8: now it clusters. | 15:40.05 |
| mvrhel_laptop | ray_laptop: ok looks good as it matches Adobe. | 15:41.05 |
| | Now we just need to get the information through the clist and the transparency structures | 15:41.25 |
| ray_laptop | mvrhel_laptop: I should have that in a bit (working on it now) | 15:41.54 |
| mvrhel_laptop | great | 15:42.01 |
| | Are you adding so that it makes it through the clist too? | 15:42.16 |
| ray_laptop | mvrhel_laptop: I'm pretty much just adding Matte_components and Matte (array of floats) everyplace Background_components and Background are | 15:42.51 |
| mvrhel_laptop | ray_laptop: That should get it through we will need to figure out where to keep the information though so that I have it for pdf14_compose_group | 15:53.18 |
| | transfer_fn might be a better model for what we want to do | 15:55.01 |
| | as that is a member of maskbuf (type pdf14_buf) | 15:55.28 |
| | ray_laptop ^^ | 15:55.37 |
| | brb | 15:55.44 |
| ray_laptop | mvrhel_laptop: OK, I figured that you could take it from gs_pdf14trans_params_s | 15:56.27 |
| mvrhel_laptop | ray_laptop: It needs to persist until the pop group occurs | 16:15.04 |
| | likely as a member variable of pdf14_buf | 16:15.40 |
| | for the mask buffer | 16:15.52 |
| | I have an appt. to run to. bbab | 16:20.39 |
| | bbiab | 16:20.41 |
| ray_laptop | mvrhel_laptop: I will email a patch to you (for use with "git am") | 17:43.38 |
| | compiling now... | 17:43.48 |
| | mvrhel_laptop: patch sent. | 17:55.26 |
| HenryStiles | ray_laptop: I have a suspicion virtual printers are dead with windows 10, I am not seeing current solutions on the web, everything looks dated. Do you know of anything. | 18:07.15 |
| | ? | 18:07.16 |
| Robin_Watts | HenryStiles: What sort of printer are you trying to set up? | 18:10.25 |
| HenryStiles | a virtual windows printer that creates pdf like primopdf and others used to do. | 18:11.04 |
| Robin_Watts | Print to PDF is built in on windows 10. | 18:15.24 |
| | So is there a case other than PDF you want? | 18:18.41 |
| | Supposedly you can still set up a virtual PS printer. | 18:19.05 |
| | http://www.file-extensions.org/article/how-to-install-a-virtual-postscript-printer-in-windows | 18:19.30 |
| HenryStiles | with print to pdf it would make the whole industry dead that explains it. I thought it was just print to XPS ... the do need to support old versions of windows also. | 18:21.11 |
| | I'm not sure if the windows print to pdf gives them the flexibility they want though. I've referred them to one of our customers that used to make virtual printer products. We'll see how that goes. | 18:25.09 |
| sebras | fredross-perry: I just created the first UnderlineAnnotation object, but it still can't be manipulated. | 18:28.11 |
| fredross-perry | Nice | 18:28.35 |
| sebras | fredross-perry: I'm thinking that I should make that manipulatable, get that merged and then add the other annotations as I get them ready. sounds good? | 18:29.05 |
| | didn't know which one to start with, but that one seemed reasonable. :) | 18:29.23 |
| fredross-perry | When you say manipulateable, what do you mean exactly? | 18:29.41 |
| sebras | fredross-perry: seems like MarkupAnnotation.setQuadPoints() is one of the more important methods? | 18:29.49 |
| | fredross-perry: that you can create the annotation, set where on the page it should appear and then update its appearance so it it is visible and rerender the page. | 18:30.25 |
| | fredross-perry: skipping things like moving it or deleting it. | 18:30.40 |
| | for now. | 18:30.42 |
| fredross-perry | I'd like to see deleting, since we've got that in our early UI design. | 18:31.08 |
| sebras | fredross-perry: that way I believe that you can start to think about how to get the annotation editing hooked up to the JNI-stuff. | 18:31.16 |
| | fredross-perry: shouldn't be too hard to do. | 18:31.30 |
| fredross-perry | thanks. | 18:31.33 |
| | I am thinking highlighting and ink for starters. | 18:31.47 |
| sebras | fredross-perry: ok. I started on Underline, but I think that is similar to Highlighting, right..? | 18:32.18 |
| fredross-perry | Yes, similar. | 18:33.26 |
| sebras | fredross-perry: I think it is just a slight difference in rendering between Highlight, Underline, Squiggly and StrikeOut. | 18:33.27 |
| fredross-perry | Agreed. | 18:33.35 |
| | They all apply to selected text in the UI. | 18:33.53 |
| sebras | fredross-perry: and Underline has a finite list of points. | 18:33.53 |
| | fredross-perry: not InkAnnotation. | 18:34.39 |
| fredross-perry | Interesting. I would associate Highlight, Underline, Squiggly and StrikeOut with a run of text, not necessarily with locations. | 18:35.01 |
| sebras | fredross-perry: being able to create the UnderlineAnnotation object means that the java objects have been chained together to create annotations at least. | 18:37.57 |
| fredross-perry | ok | 18:38.15 |
| sebras | fredross-perry: so MarkupAnnotation.setQuadPoints() and PDFAnnotation.updateAppearnce() is probably what I should focus on next. at least if MuPDFCore_addMarkupAnnotationInternal() from the existing app is something to go by. | 18:41.07 |
| fredross-perry | yes | 18:41.31 |
| sebras | I hope this is enough to get the annotation visible. | 18:42.22 |
| | once we get to that point I'll start working on InkAnnotation. | 18:43.12 |
| | fredross-perry: I have no clue if not having this available to you ASAP is blocking you some how. let me know that is the case. | 18:45.13 |
| fredross-perry | It's not blocking me. I've got some work to do for file saving next, and wrapping up proofing. But you can give me Highlight, Underline, Squiggly and StrikeOut one at a time if you like. | 18:51.39 |
| sebras | fredross-perry: great. | 18:52.15 |
| sebras | sleeps. | 19:13.27 |
| | Forward 1 day (to 2016/09/08)>>> | |
IRC Logs