| <<<Back 1 day (to 2013/06/19) | 2013/06/20 |
mvrhel_laptop | oops I did not know you were typing to me Robin_Watts | 00:47.18 |
| Robin_Watts: yes, we should be able to stream bits and pieces and start using them | 00:48.10 |
| application is submitted. | 00:48.22 |
| dinner time, then I will work on my P1 gs bugs | 00:48.35 |
kens | chrisl I see that 'slow printing' bug is down to a Cairo produced file using spurious transparency again. | 07:38.56 |
chrisl | kens: I am not surprised. But James Cloos's results don't match the original reporter's | 07:41.56 |
kens | Well it doesn't take minutes, certainly | 07:42.11 |
chrisl | Well, in terms of printing, 20 seconds is not *crazy* - it can take that long to print directly from the browser | 07:43.15 |
kens | But... The PostScript file after conversion (compressed) is 3Mb, basically its been converted to images. The whole pipeline might have a problem with that. Also, the rendering will be at 720 dpi, so if he's short on memory it will start swappung, which will take still more time | 07:43.18 |
chrisl | Well, that's what you get with pointless transparency - tough sh*t! | 07:43.52 |
kens | I've suggested tey try with -dNOTRANSPARENCY or with a lower resolution, and I've left teh bug open for now. | 07:44.07 |
| I'm considering checking the Producer string for 'Cairo' and setting -dNOTRANSPARENCY if its present | 07:44.35 |
| And emitting a warning. Obviously a different switch would force us past that | 07:44.58 |
chrisl | Well, we *might* be able to augment our transparency checks, but my worry is that I've seen at least one example with a "opaque soft mask", and it doesn't make sense to check every sample in an smask | 07:45.55 |
kens | chrisl exactly why I discounted that (this file has several of those) | 07:46.16 |
chrisl | Well, I *really* think emitting opaque softmasks is a cairo bug, that really is crazy | 07:47.01 |
kens | I was thinking of turning off transparency for *all* Cairo files and emitting a warning along he lines of 'This file was produced by Cairo which is know to emit supurious transparency which adversely affects performance. Transparency has been disabled, if your file prints incorrectly use -DSTUPIDCAIRO and try again' | 07:47.28 |
chrisl | I think that may be too subtle.... | 07:48.17 |
kens | :-) | 07:48.22 |
| It would get us out of this stupid situation though. | 07:48.39 |
chrisl | Well, I suppose it's worth a try | 07:49.11 |
kens | I'm going to get a coffee and see if that would be easy to do | 07:49.12 |
tor8 | morning paulgardiner, Robin_Watts | 11:14.48 |
paulgardiner | Hi tor8 | 11:14.59 |
tor8 | paulgardiner: have you had a chance to look at the shuffle branch? | 11:15.17 |
paulgardiner | looks | 11:16.21 |
| Why isn't git recognising the file movments? | 11:18.40 |
| Oops. Looking via gitweb overloads FF | 11:19.09 |
| Actually, a set of mv commands would possibly be an easier thing to review | 11:20.26 |
| Ah. gitk show them as moves | 11:20.43 |
tor8 | paulgardiner: I don't know, neither gitweb nor gitk seem to show file renames and copies | 11:20.44 |
paulgardiner | similarity index 100% :-) | 11:21.19 |
tor8 | I think there may be a configure flag for gitweb to show moves. detecting file moves is a bit computationally heavy I think. | 11:21.22 |
paulgardiner | Seemed to work here okay, and without a noticable delay | 11:21.57 |
tor8 | let me take a look at gitweb config | 11:22.49 |
paulgardiner | I tend to use gitk a fair bit anyway, so no bother for me | 11:23.28 |
| First one looks good. | 11:25.16 |
| ... well, commit message could say more maybe | 11:25.36 |
tor8 | paulgardiner: okay, gitweb config change was trivial | 11:26.32 |
paulgardiner | dev_xxxx => xxxx-device will make it harder to quickly see what devices we have and harder to find a particular file... but then again, we don't have that many files, and I guess we might introduce a device subdir eventaully | 11:27.41 |
tor8 | paulgardiner: yeah. the biggest problem with dev-xxx rather than xxx-dev is when there are mulitple files for a device | 11:28.36 |
| like the draw and structured-text devices | 11:28.42 |
paulgardiner | Ah right | 11:28.55 |
| What's "stext"? I think you said yesterday, but I forget | 11:29.24 |
tor8 | though moving the devices into a device directory would solve that easily enough. but that's for later. | 11:29.27 |
| structured text | 11:29.30 |
paulgardiner | ah yes | 11:29.39 |
tor8 | the text extraction stuff used for searching | 11:29.42 |
| the plain "text" is the raw text that's fed to the device calls | 11:29.56 |
| we may want to rename the structs as well | 11:30.09 |
| but since I think we're going to be messing with the text extraction stuff a lot more later I'm leaving that for now | 11:30.25 |
paulgardiner | Second looks good too | 11:30.36 |
| All looks good. | 11:31.52 |
tor8 | paulgardiner: I had a few thoughts about the pdf/javascript file names | 11:32.01 |
| I split libmupdf.a into three libraries for the unix build | 11:32.17 |
| libmupdf and libmupdf-js-none and libmupdf-js-v8 | 11:32.26 |
| so if a client is using javascript, they should also link to the js implementation library | 11:32.58 |
| of their choice | 11:33.02 |
paulgardiner | presumably they have to link one or other whatever they are doing? | 11:33.39 |
tor8 | the pdf/js/ file names, pdf-js.c has the implementation independent calls that the pdf-jsimp stuff calls to? | 11:34.03 |
| I think if you're not calling any of pdf_ew_js or pdf_js_supported you can skip linking to either | 11:34.41 |
paulgardiner | I thought open doc led to a call to pdf_new_js | 11:36.37 |
tor8 | paulgardiner: right you are, so it does :( | 11:37.02 |
kens | heads off to lunch | 11:37.04 |
tor8 | I wonder if that can be done lazily instead | 11:37.51 |
paulgardiner | I bet there's a way to achieve what you want, but it probably requires function pointers | 11:38.04 |
| pdf_use_js_imp(doc, js_imp) or something like that. | 11:38.38 |
tor8 | paulgardiner: probably not worth it, though. just need to remember to link to the js-none layer. | 11:38.54 |
paulgardiner | We then build the none behaviour in as default | 11:39.00 |
tor8 | I don't know enough about linker priorities when the same symbol exists in multiple libraries | 11:39.14 |
paulgardiner | yeah. linking none is less complication | 11:39.21 |
tor8 | it would be nice to be able to link to the none implementation by default, and still use the v8 if that one is present on the link line | 11:40.09 |
| but less complication is better :) | 11:40.14 |
paulgardiner | I don't think the function -ointer solution would assume any linker specifics, but it would be an extra complication | 11:40.25 |
| Oh yes, definitely less complication is good | 11:40.41 |
tor8 | how are pdf-js.c pdf-js-none.c and pdf-jsimp-(cpp|v8).c(pp) related? | 11:41.41 |
| i.e. how much overlap is there | 11:41.48 |
| I was considering dropping pdf-js.c up one level (since it's common) and have pdf/js-none and a pdf/js-v8 subdirectories | 11:42.26 |
paulgardiner | There are two levels of interface. The high-level one is shared by pdf_js.c and pdf_js_none.c | 11:42.50 |
tor8 | right. so js and js_none are exclusive | 11:43.14 |
paulgardiner | pdf_js.c implements the high-level interface in terms of the low-level one. | 11:43.18 |
| pdf_js_imp.c implements the low-level one. | 11:43.30 |
tor8 | but js is (eventually) shared by v8 and whatever other engines we hook up? | 11:43.47 |
paulgardiner | The low-level one should be implementable with other js solutions. | 11:43.55 |
tor8 | jsimp-cpp is that v8 neutral? | 11:44.16 |
paulgardiner | pdf_js.c defines the dom, so the DOM shouldn't need redefining when using a different engine | 11:44.31 |
tor8 | right. I think I understand a bit better now. | 11:46.21 |
paulgardiner | Yes, jsimp_cpp.c is v8 neutral, but wouldn't be used if we chose a non-cpp engine | 11:47.02 |
Robin_Watts | tor8: paulgardiner: There is an updated version of the shuffle branch on robin shuffle. | 11:48.19 |
| Contains a redone win32 project. | 11:48.26 |
| I handle the openssl or not slightly differently. | 11:48.37 |
| in that I build an openssl or not libmupdf, rather than leaving the decision to the app stage. | 11:49.08 |
| paulgardiner: Did you see the support mail this morning? | 11:49.21 |
paulgardiner | Robin_Watts: not one that stands out | 11:50.30 |
Robin_Watts | From Christophe. I replied to it? | 11:50.42 |
| I think he needs to create annotations. | 11:50.52 |
paulgardiner | Oh right. Possibly | 11:51.10 |
Robin_Watts | printed pdf page with watermark. | 11:51.18 |
| I said I'd speak to you about some example code that used it. | 11:51.34 |
| Presumably there are limitations, like having to use the fonts already in the document etc? | 11:51.53 |
paulgardiner | That looks like a Text annotation | 11:52.36 |
| We haven't gotten to those yet, but they are definitely on the list | 11:53.00 |
Robin_Watts | paulgardiner: Ah, bugger. | 11:53.15 |
| Christophe is from our main mupdf customer. Keeping them happy is a priority I think. | 11:53.36 |
| We may have to speak to henrys about doing them sooner rather than later. | 11:53.51 |
paulgardiner | Like other's I'd hope the annotation could be done via the pdf device, but I don't know how well it supports text | 11:53.59 |
Robin_Watts | paulgardiner: The lack of control over fonts is the hard part. | 11:54.18 |
paulgardiner | Robin_Watts: I'd be happy to make it a priority, but yes asking henrys would be good | 11:54.20 |
Robin_Watts | Currently we don't have code in place to add new fonts to a page. | 11:54.42 |
tor8 | Robin_Watts: the ucdn msvc warnings can be disabled if we include "fitz/system.h" | 11:55.06 |
paulgardiner | Depending on your other priorities, it might make sense for you to handle the pdf device changes and I could do the rest | 11:55.15 |
Robin_Watts | paulgardiner: It might. Let's speak to henry when he appears. | 11:55.30 |
paulgardiner | I'm not exactly in a great stopping place with the incremental-update work, but still not disasterously so. | 11:56.38 |
tor8 | Robin_Watts: why does ucdn.c compile to ucdn1.obj? there's a 1 added in the Output Files property panel... | 11:58.20 |
| intended or not? | 11:58.27 |
Robin_Watts | not intended by me. | 11:59.10 |
tor8 | probably automatic to prevent collisions then... maybe a side effect of moving things around? | 11:59.54 |
| Robin_Watts: any reason the "script" header files are in the "generated" project? | 12:04.14 |
Robin_Watts | where else would they be? | 12:09.00 |
| paulgardiner: Tiny change on robin/master (some comment renames that were missed) | 12:11.14 |
paulgardiner | Looks fine | 12:14.23 |
tor8 | argh. cmd doesn't expand wildcards on win32, and nor does the libc when calling main()? | 12:15.17 |
| that's ... annoying | 12:15.21 |
| Robin_Watts: the ftoptions.h etc have nothing to do with generated | 12:15.42 |
| Robin_Watts: the generate.bat is broken, I'm trying to fix it now | 12:16.02 |
| and ran into the problem with wildcards :( | 12:16.11 |
Robin_Watts | tor8: is it? It was working for me. | 12:16.31 |
tor8 | Robin_Watts: only if you have an existing generated/ directory | 12:16.50 |
| it has the wrong paths to the resource files | 12:17.02 |
paulgardiner | tor8, Robin_Watts: I've run into a naster problem with incremental update, that may be easily solved by making the xref's update_appearance function pointer take a pdf_annot * rather than the pdf_obj * that the pdf_annot * refers to. | 12:27.17 |
| s/naster/nasty/ | 12:27.32 |
| But I can't remember whether making it take an obj was something we did to prevent certain builds dragging in unnecessary fonts or the like | 12:28.50 |
Robin_Watts | Searching for update_appearance, I can't find anything that assigns it. | 12:29.08 |
paulgardiner | In pdf_xref_aux.c | 12:29.27 |
| Actually I think it should be okay, because in the case where we don't want to drag stuff in, we don't assign it | 12:29.51 |
Robin_Watts | I can't remember any such issue. | 12:30.14 |
paulgardiner | I can't remember it well, but I had to make update_appearance virtual for some reason | 12:30.52 |
Robin_Watts | so you want to pass in annot rather than obj? | 12:31.28 |
| and presumably there is a way to get the obj from the annot ? | 12:31.37 |
| I can't see an objection to that offhand. | 12:31.54 |
paulgardiner | Ah red herring... well sort of... there's another problem with passing a pdf_annot: there's a caller that doesn't have access to a pdf_annot | 12:32.37 |
Robin_Watts | What is the problem you need the annot to solve ? | 12:32.59 |
paulgardiner | I'm, in some cases, changing the obj and I don't want the annot to point to the old obj | 12:34.14 |
Robin_Watts | Can you change the caller to have access to the pdf_annot? | 12:35.16 |
paulgardiner | Actually the caller that doesn't have an annot is the code that creates annot, so I think I can solve it. | 12:35.55 |
| Might be best to pass an obj ** to update_appearance. | 12:36.16 |
Robin_Watts | sounds plausible. | 12:37.21 |
tor8 | Robin_Watts: two fixes to win32 project files on tor/shuffle | 12:38.13 |
paulgardiner | Ah, perhaps the appearance is guaranteed to be indirect. That would make it trivial | 12:39.26 |
Robin_Watts | I thought you said that wildcards didn't work ? | 12:39.29 |
tor8 | Robin_Watts: they do if you link with setargv.obj with cl | 12:39.45 |
| took me some google foo to figure that one out | 12:40.01 |
paulgardiner | The appearance, being a stream, surely has to be indirect | 12:40.23 |
Robin_Watts | setargv.obj is broken in VS2005 apparently :( | 12:41.18 |
tor8 | Robin_Watts: that's odd ... I use VS2005 | 12:41.31 |
Robin_Watts | for some definition of broken. | 12:41.38 |
| might just be quoting of wildcards. | 12:41.47 |
| You've removed the cmaps and the fonts from the project? | 12:43.21 |
tor8 | Robin_Watts: I didn't see much point in having them browsable from the project | 12:43.37 |
Robin_Watts | ok, looks fine. | 12:44.11 |
tor8 | if you want to see them, we should add the resources directory and subdirectories with all files (including the certs, which were missing from your version) | 12:44.17 |
| but I think it's not very important | 12:44.25 |
| we could drop the source directories in a "source" filter in libmupdf.vcproj if you think the "include" directory should be more isolated | 12:45.20 |
Robin_Watts | The include stuff is all in "api" | 12:45.33 |
| which is nice cos it's the first one :) | 12:45.43 |
| That's separate enough for me. | 12:45.58 |
tor8 | Robin_Watts: well, that's hiding the file location IMO | 12:46.14 |
| it took me a while before I realized it was the include/ directory | 12:46.53 |
Robin_Watts | The solution explorer is not intended to be a direct mirror of the file locations. | 12:49.17 |
| More of the 'structure' of the project. | 12:49.30 |
| tor8: did you see the bug about the makefile install target being wrong ? | 12:50.03 |
| header files are going into /usr/include/ rather than /usr/include/mupdf/ | 12:50.29 |
tor8 | ah right! | 12:50.39 |
| I remember going to "man install" to figure that one out then I got sidetracked... | 12:51.01 |
| Robin_Watts: okay, new patch on tor/shuffle that rearranges the project files to my liking. | 12:51.20 |
| feel free to disagree with my choices and whine loudly. you're after all the main user of the project. | 12:51.38 |
Robin_Watts | I dislike sticking everything in source. | 12:54.29 |
| it's just one more thing to have to click. | 12:54.39 |
tor8 | msvc remembers what was last opened between invocations | 12:56.21 |
Robin_Watts | tor8: yeah, but it's a pointless extra layer | 12:56.44 |
kens | That depebnd on th settings | 12:56.52 |
tor8 | not pointless, it mimics the file layout | 12:57.03 |
Robin_Watts | For use in the solution explorer, it's pointless, IMHO. | 12:57.43 |
| but it's a small thing, I can live with it. | 12:57.51 |
tor8 | if only you could sort things manually in the solution explorer... we wouldn't be having this discussion :) | 12:58.55 |
| but I really didn't like the "api" filter | 12:59.14 |
| but then I'm terribly easily confused, and think about our poor customers ;) | 12:59.35 |
henrys | paulgardiner, Robin_Watts: the customer has priority but I haven't read any email yet so don't understand how it affects each of you. | 12:59.47 |
Robin_Watts | tor8: How about using "!include" or ".include" or something, and then leaving the rest without "source" ? | 13:01.10 |
| That would put include at the top. | 13:01.30 |
tor8 | a "!include" without the mupdf sublevel could work | 13:04.57 |
| if you want maximum convenience | 13:05.02 |
| Robin_Watts: like on tor/shuffle ? | 13:06.56 |
Robin_Watts | Looks good to me. | 13:08.50 |
henrys | paulgardiner: I guess you just have to switch to text annotations unless he says it isn't urgent. Sorry | 13:18.22 |
paulgardiner | henrys: Yeah no worries. I may have part of this commitable today in any case. | 13:20.44 |
tor8 | Robin_Watts: a handful new commits on tor/master | 13:36.33 |
| if they're okay, should I squash and push to master? | 13:36.42 |
| I guess we need to fix the android build though | 13:37.18 |
Robin_Watts | tor8: let me look. | 14:10.02 |
| tor8: V8_PRESENT=1 or 0, not yes. | 14:15.52 |
| otherwise looks great. | 14:16.58 |
| Personally, I'd squash and push and we can fix android later. | 14:17.08 |
| It's already broken :) | 14:17.15 |
| henrys: mvrhel found a PDF Reader for Win8 that he thought was based on MuPDF. | 14:20.32 |
| They claim to be GPL v3 licensed. | 14:20.55 |
| so I asked the authors for a copy of the source, and they have just given me access to a bitbucket git repo. | 14:21.15 |
henrys | yes I spoke to michael about it. | 14:21.18 |
Robin_Watts | They are indeed based on mupdf. | 14:21.28 |
henrys | sounds legal to me, what's the problem? | 14:22.00 |
Robin_Watts | The git repo doesn't have the mupdf source in it, just compiled .dll/.pdb/.winmd for ARM and intel. | 14:22.00 |
henrys | but their code is present? | 14:22.17 |
Robin_Watts | And they've removed the tokens required for SkyDrive api and BugSense api. | 14:22.37 |
| I don't reckon they are GPL compliant. | 14:22.57 |
henrys | so they have modified mupdf and have not republished? | 14:23.39 |
Robin_Watts | Well, I don't believe they are using michaels winrt stuff. | 14:24.21 |
| so they must have done makefiles/projects and I can't see them being released here. | 14:24.45 |
| also, having to ask for a source code link is against my understanding of the GPL. | 14:25.12 |
| I thought that you should get the source code link as part of the package. Otherwise if they "go bust" or disappear or whatever, users are stuffed. | 14:25.54 |
henrys | Robin_Watts:I agree about the link, but that is easily remedied so the question becomes is it worth opening a discussion. | 14:26.13 |
Robin_Watts | Also, I'm not sure that the GPL allows for them not to publish sections of the code as they are security sensitive. | 14:26.44 |
henrys | well michael did send this off to Miles and Scott. Did you want me to follow up with them? | 14:27.16 |
Robin_Watts | henrys: I should probably forward this on to them as additional information. | 14:27.35 |
| I will do that. | 14:27.57 |
tor8 | Robin_Watts: d'oh forgot the Makerules in that commit | 14:33.29 |
Robin_Watts | "yes" is bad, IMHO. | 14:33.41 |
tor8 | Robin_Watts: it's what we use elsewhere (NOX11 and CROSSCOMPILE) | 14:34.07 |
Robin_Watts | oh, well, consistency wins then :( | 14:34.19 |
tor8 | and for the pkg-config openssl test | 14:34.39 |
paulgardiner | Robin_Watts, tor8: is master reasonably stable now, or are is more shuffling imminent? Wondering whether to rebase some stuff or leave it until stability | 14:42.36 |
Robin_Watts | paulgardiner: Much more shuffling, I fear. | 14:43.27 |
tor8 | paulgardiner: shuffling is imminent I think | 14:43.33 |
paulgardiner | Okay. I'll stick where I am in the tree for now.. Thanks | 14:43.55 |
tor8 | Robin_Watts: squashed shuffle on tor/shuffle | 14:49.36 |
| should I push to master? | 14:49.41 |
Robin_Watts | go for it. | 14:49.49 |
tor8 | hah! got an error from the git hooks: sendmail fatal: message file too big | 14:50.32 |
Robin_Watts | tor8: cluster is unhappy with some of those commits. Is that expected? | 15:04.29 |
henrys | my state is burning again: https://maps.google.com/maps/ms?msid=215563989566450268982.0004c328de8016253230a&msa=0&ie=UTF8&t=m&ll=39.943436,-106.391602&spn=16.827379,26.323242&z=5&source=embed&dg=feature | 15:04.45 |
| paulgardiner: scott was asking sabrina about the diet. Looks like he's going to try it. | 15:05.20 |
tor8 | Robin_Watts: yes. the makefile changes went in a separate patch so some are expected to be broken. | 15:06.02 |
paulgardiner | Ah. Another convert. | 15:06.18 |
tor8 | Robin_Watts: mujstest failing on the second commit is a bit more suspicious | 15:07.33 |
paulgardiner | I'm definitely finding it easier | 15:08.09 |
henrys | paulgardiner: sabrina may go to one day, she's down to her "fighting weight" now. | 15:08.20 |
paulgardiner | I'm so jealous :-) | 15:09.38 |
Robin_Watts | I'm down to the right weight. I just need to grow another 6 inches. | 15:10.00 |
paulgardiner | :-) | 15:10.26 |
henrys | Robin_Watts: you looked to be in pretty good shape at the meeting Robin_Watts | 15:13.08 |
Robin_Watts | henrys: Every time I come to a staff meeting/go on holiday I gain 7 pounds, and then only lose 5 before the next meeting. | 15:13.48 |
| I need to lose another 7 or so to get back to where I'm happy. And would then need to lose another 10 or so before I'm within my BMI. | 15:14.25 |
henrys | skim milk shakes? | 15:14.57 |
Robin_Watts | I failed entirely to get any milkshakes in miami. | 15:15.16 |
| only got one in boston. | 15:15.20 |
kens2 | ick :-( | 15:15.33 |
kens2 | coffees | 15:16.20 |
henrys | i just noticed that you guys drink coffee and tea late in the afternoon. It's morning here and I didn't think about it before. | 15:19.16 |
kens2 | I drink coffee all day and evening :-) | 15:20.51 |
Robin_Watts | henrys: You only drink coffee in the morning? | 15:24.51 |
henrys | Robin_Watts: mostly yes. | 15:25.49 |
ray_laptop | The first I knew about Miles was the "I'm OK" message. Spam must have gotten the email about what he was to undergo :-( | 15:28.12 |
| but I'm glad he's OK | 15:28.21 |
Robin_Watts | ray_laptop: He mentioned it at the staff meeting. | 15:28.35 |
| There was no "see you on the other side" email. | 15:28.48 |
henrys | ray_laptop has an auditory spam filter he engages at the meetings ;-) | 15:29.20 |
Robin_Watts | :) | 15:30.07 |
paulgardiner | L-) | 15:31.03 |
| :-) even | 15:31.08 |
ray_laptop | I thought that Miles was whitelisted (mostly I just filter Scott) | 15:34.42 |
| I need mvrhel when he shows up. | 15:35.50 |
| the 'spread' in the image enum seems to be confused (or is confusing me) | 15:36.48 |
| the sample "unpack" procedures all have many components that are ignored :-( | 15:38.13 |
Robin_Watts | ray_laptop: Is it not the case that we may look at the components when selecting unpack procedures? | 15:40.59 |
| if we have selected an unpack procedure based on the fact that it accepts input in a given format, is it surprising that that procedure doesn't check to verify that format every time it's called? | 15:42.15 |
| paulgardiner/tor8: I've brought pdfwrite up to date to just before the shuffle. | 15:48.48 |
| I really need to get that committed as rebasing it again and again is getting tiring :) | 15:49.09 |
| tor8: Have you looked into the cluster failures? | 15:49.38 |
| oh! | 15:50.16 |
| The cluster is trying to build mujstest-v8 | 15:50.25 |
| and you renamed it to mujstest-js or something? | 15:50.34 |
paulgardiner | I'm out tonight and have to disappear soonish | 15:51.28 |
ray_laptop | Robin_Watts: no, my confusion is that we have so many parameters and I don't see any proc (yet) that uses them | 15:51.33 |
Robin_Watts | paulgardiner: Did you need something done before you disappear? | 15:51.54 |
| I have to pop out for a bit in a bit too. | 15:52.13 |
paulgardiner | No thanks. Just commenting on the limited time I have to look at pdfwrite | 15:52.23 |
| Before tomorrow that is | 15:52.35 |
Robin_Watts | paulgardiner: Ah. I wasn't expecting it looked at today. | 15:52.39 |
paulgardiner | oh okay | 15:52.46 |
ray_laptop | also, I need to check with mvrhel about the color monitoring stuff -- in particular the 'bsize' calculation seems funky (at least for 12-bit) since it uses bps but unpack expands 12 to 16 bit | 15:52.47 |
Robin_Watts | I'll have to updated it through the shuffle yet. | 15:52.53 |
ray_laptop | oh, disregard that last. It just uses bps to decide whether to have 1 or 2 bytes per sample | 15:53.35 |
Robin_Watts | tor8: The cluster uses NOX11=1 | 16:01.27 |
| tor8: The default build target does not include mujstest-v8 now. | 16:10.18 |
| JSTARGETS isn't set. | 16:11.32 |
| Will fix when I get back. | 16:13.32 |
kens2 | Robin_Watts : I've forwarded an email from a free user that I'm not qualified to answer. If you have the time could you give him a quick reply please. | 16:22.24 |
| Right, time to go. Goodnight everyone | 16:27.02 |
tor8 | ah, right. | 17:10.46 |
| Robin_Watts: makefile fix on tor/master | 17:33.59 |
| the JSTARGETS variable isn't needed anymore (the XXX_V8 variables are only set if V8_PRESET == yes) | 17:34.55 |
sebras | Robin_Watts: how did you find out about that winrt-app using mupdf? | 18:21.56 |
mvrhel_laptop | henrys: Is Joann going to be in the office today | 18:31.24 |
| so microsoft has to verify the Artifex store account only through the main office phone number | 18:32.07 |
| After re reading your email, I actually had given them your 303 number but they found the Artifex main number and can only call and verity through that number | 18:32.49 |
| but no one appears to be answering the phone | 18:33.08 |
Robin_Watts | tor8: yeah, I have the same fix on peeves - I didn't get a chance to push it before I had to run out. | 18:33.19 |
| tor8: hmm. My fix preserved the all-nojs target. | 18:34.24 |
| I guess it doesn't really matter. | 18:34.37 |
henrys | mvrhel_laptop: maybe since she knows miles won't be there⦠;-) I don't know. | 18:39.21 |
mvrhel_laptop | doesn't the main line roll over to scott too sometimes? | 18:39.42 |
Robin_Watts | She might be running to the post office or something? | 18:41.16 |
mvrhel_laptop | anyway, back to the gs salt mine to work on overprint simulation | 18:41.35 |
Robin_Watts | mvrhel_laptop: Apple and Android app stores have no such verification process. I can't believe MS do this for everyone. | 18:41.48 |
henrys | mvrhel_laptop: I usually send joann mail and usually get a response later in the afternoon. | 18:41.57 |
Robin_Watts | or maybe I can, and that's why they have so few apps. | 18:41.58 |
mvrhel_laptop | Robin_Watts: yes, I had to do many steps | 18:42.21 |
Robin_Watts | sebras: We guessed. It claimed to do PDF/XPS/CBZ and was GPL licensed :) | 18:42.24 |
mvrhel_laptop | Robin_Watts: those jokers are not complying with GPL | 18:42.40 |
Robin_Watts | Indeed, I reckon not. | 18:42.54 |
mvrhel_laptop | not to mention that they offer "commerical" licenses | 18:42.54 |
Robin_Watts | The question is, have they ever actually sold a commercial license? :) | 18:44.10 |
mvrhel_laptop | yes | 18:44.23 |
Robin_Watts | Yes, they have? or yes, that is the question? | 18:44.50 |
mvrhel_laptop | yes that is the question | 18:44.57 |
Robin_Watts | yeah. | 18:45.01 |
mvrhel_laptop | if I knew the answer to that question we would be having a different discussion likely | 18:45.12 |
Robin_Watts | Well, I passed the info onto Miles etc, so he can make the call. | 18:45.22 |
mvrhel_laptop | right. thanks. | 18:46.12 |
Robin_Watts | I could harry them on their facebook page, but I don't want to do that if Miles is going to try to pull them in to a commercial deal. | 18:46.20 |
mvrhel_laptop | right. Best to wait and see what happens | 18:46.57 |
Robin_Watts | balls. cluster expects the all-nojs target. | 18:50.57 |
| I'm tempted to think we ought to keep the all-nojs target working, as it means mupdf tests on the cluster won't fall over if we break js, just the mujstest ones. | 18:52.46 |
| tor8: Urm... I'm confused. | 19:04.52 |
| fz_draw_stroke_path. We calculate the expansion from the ctm. | 19:05.09 |
| Then we do: if (linewidth * expansion < 0.1f) linewidth = 1/expansion; | 19:05.31 |
| That makes no sense to me. | 19:05.42 |
| Suppose we have a linewidth just below 0.1/expansion. That will be bumped up by almost a factor of 10. | 19:06.44 |
| but a linewidth just above 0.1/expansion will be left as is. | 19:06.56 |
| I suspect the code is intended to be: if (linewidth *expansion < 0.1f) linewidth = 0.1f/expansion; | 19:07.27 |
| or am I missing something? | 19:07.32 |
ray_laptop | mvrhel_laptop: I have a question about the color monitoring. Do you have a second ? | 19:11.14 |
mvrhel_laptop | ray_laptop: yes | 19:11.46 |
ray_laptop | mvrhel_laptop: thanks. the 'row_has_color' function calls the selected is_neutral function, such as gsicc_mcm_monitor_rgb, but it passes in pie_c->spread as 'num_bytes' | 19:12.56 |
mvrhel_laptop | ray_laptop: hold on let me get there | 19:13.18 |
ray_laptop | gxclimag.c line 406 | 19:13.39 |
mvrhel_laptop | and refresh my brain what spread was. was this bits | 19:15.15 |
Robin_Watts | spread sounds suspiciously like "how many bytes to get from one sample to the next" | 19:15.54 |
ray_laptop | mvrhel_laptop: it is set by get_unpack_proc (a copy of what's in gxipixel.c ) | 19:16.23 |
| same file, line435 | 19:16.39 |
mvrhel_laptop | oh yes | 19:16.50 |
ray_laptop | it's set differently if it's planar vs. chunky | 19:16.59 |
mvrhel_laptop | well that is not going to work | 19:17.11 |
| oh wait | 19:17.22 |
ray_laptop | it works for chunky since it is the number of bytes | 19:17.27 |
mvrhel_laptop | right | 19:17.32 |
ray_laptop | i.e., i << log2_xbytes | 19:17.44 |
mvrhel_laptop | right. that is a big goof up | 19:17.51 |
| sorry about that | 19:17.54 |
ray_laptop | 1 << log2_xbytes | 19:17.58 |
| mvrhel_laptop: that's OK. I was just making sure that the 'monitor' functions expect either 2 or 1, never bigger | 19:18.46 |
mvrhel_laptop | ray_laptop: yes, they are just set up for 2 or 1 | 19:19.01 |
| either we will need to change that or repack the data into a chunky bit prior to calling the is neutral proc | 19:19.28 |
ray_laptop | so the unpack proc will use the 'spread' to space the data out when it unpacks, so I can put the components together. | 19:19.46 |
Robin_Watts | is it feasible to have a different set of is_neutral functions for planar or chunky? | 19:20.37 |
ray_laptop | mvrhel_laptop: OK, so I can use a much simpler modification. now. Just have to compute the num_bytes for is_neutral differently (so that it will work for planar images) | 19:21.01 |
mvrhel_laptop | anything is feasible in ghostscript | 19:21.02 |
| ray_laptop: yes. sorry for the screw up | 19:21.36 |
ray_laptop | Robin_Watts: yes, but since I need to unpack the planes into the buffer, I can put them into chunky format and not need extra routines | 19:21.54 |
| I just need to pull the 'unpack' out of row_has_color and I should be OK. | 19:22.30 |
| I'm not sure about gs_image_format_bit_planar, but I don't think I've ever seen one of those | 19:23.23 |
| where the bits for each component are in separate data sources | 19:23.51 |
| while it seems to be tested and allowed for various places in the code, it never seems to be set to that value | 19:25.20 |
tor8 | Robin_Watts: I have no recollection of that code. | 19:38.28 |
| better double check it against what libart and ghostscript does | 19:38.46 |
Robin_Watts | ghostscript does something entirely different. | 19:39.00 |
tor8 | I think I based some of the stroking on what libart did | 19:39.13 |
Robin_Watts | tor8: what do you propose we do about all-nojs: ? | 19:39.22 |
tor8 | (libart is raph's old pre-cursor to fitz) | 19:39.22 |
| Robin_Watts: we could add libs-nojs and apps-nojs targets as well | 19:39.55 |
| or build with "make V8_PRESENT=no" ? | 19:43.17 |
Robin_Watts | tor8: I could change the cluster code to do that. | 19:43.43 |
| The cluster builds with NOX11=1 | 19:43.56 |
tor8 | NOV8 might be more in line with NOX11, or change both to HAVE_X11, HAVE_V8 ? | 19:44.26 |
Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=blob;f=fitz/dev_draw.c;h=cd3613e3309125ab9358c1e7af52bd2b72c4c63d;hb=bfce5d9eafe093e2e397fbb7e0afa4eb236c4746 | 19:44.35 |
| Line 60/61 | 19:44.40 |
| So that code has been there since the first commit of dev_draw.c | 19:44.54 |
tor8 | oh right! that one. | 19:44.57 |
| now I remember | 19:45.04 |
| if (hairwidth) linewidth = 1 device pixel | 19:45.17 |
Robin_Watts | right. but that suffers from being non monotonic. | 19:45.51 |
tor8 | yeah. it's got a hard jump. | 19:46.23 |
| sadly, I've found we need to trigger on values != 0 for hairline widths | 19:46.46 |
| one (not so good) alternative is setting a minimum device line width | 19:47.24 |
Robin_Watts | ok, at least I understand it now. | 19:47.45 |
| thanks. | 19:47.47 |
ray_laptop | mvrhel_laptop: is there a reason you used pclcs.icc_info.icc_num_components instead of pie_c->spp in "row_has_color" ? | 20:16.45 |
| I can't seem to access the git repository for gs. I get FATAL ERROR: No supported authentication methods available | 20:32.07 |
mvrhel_laptop | ray_laptop: yes but I can't remember why | 20:35.30 |
| you can change it, if you wish | 20:35.47 |
ray_laptop | mvrhel_laptop: I don't really want to change it without knowing why it was used in the first place | 20:37.35 |
mvrhel_laptop | ray_laptop: they should be the same | 20:38.02 |
| if they are not, then bad things would happen | 20:38.24 |
| it is possible that in the case of a separation color space or device N color space they could be different though. | 20:39.10 |
ray_laptop | mvrhel_laptop: but we don't worry about those for monitoring, right ? | 20:40.38 |
| i.e., we assume they are 'color' | 20:41.08 |
| I'm going to reboot to see if my 'git' fixes itself. bbiab... | 20:42.22 |
mvrhel_laptop | weird. where I was getting segv's before with my patch on the cluster, now it all seems to be ok | 21:43.58 |
| differences to review | 21:44.12 |
| good grief. so MS requires another $99 so that you can submit apps to the phone store | 22:02.57 |
| it is different than the windows 8 store | 22:03.33 |
| ok. some visible issues with the ghent overprint files when going to certain devices | 22:11.04 |
| should be easy to track this down | 22:11.10 |
ray_laptop | Rebooting didn't cure my git problem. I'm still getting FATAL ERROR: Disconnected: No supported authentication methods available | 23:24.48 |
| I can plink to ghostscript.com and I have: remote.origin.url=ray@ghostscript.com:/home/git/ghostpdl.git | 23:25.27 |
| Does anybody have any ideas what I need to look at ? | 23:27.06 |
| mvrhel_laptop: I sent an email with the patch for you to review (until I can figure out what happened to my 'git') | 23:42.37 |
| mvrhel_laptop: BTW, I noticed that there is what looks like a naming issue. The gscms_procs_s has gscms_monitor_proc_t is_color but this returns "true" when the color is "neutral". Shouldn't this proc be named "is_neutral" ??? | 23:46.08 |
| Forward 1 day (to 2013/06/21)>>> | |