| | <<<Back 1 day (to 2013/04/29) | 2013/04/30 |
| JAFA_afk | Is this somewhere I can beg a little help with using muPDF on my Android tablet? | 06:28.28 |
| | nvm, once I gave up looking for it, I found my answer by accident. :\ | 06:30.13 |
| | BTW, I'm new to muPDF, but if any of the devs see this, I like it so far, thanks! | 06:30.39 |
| tor8 | Robin_Watts: ping. | 08:49.37 |
| Robin_Watts | pong | 08:49.44 |
| tor8 | dev_text.c has grow to be a bit too big. any objections to me splitting it into three pieces? | 08:50.57 |
| | one for raw span extraction, one for paragraph analysis and a third for html output | 08:51.11 |
| | and one question about the struct layout. the different pointedness of the blocks/lines/spans/chars makes iterating through them rather ugly. I'm thinking of adding a few simple macros: fz_for_each_text_line(line, block), etc | 08:52.35 |
| Robin_Watts | tor8: no objection to splitting. | 08:55.59 |
| | Macroisation... not so keen, really, unless it works really nicely. | 08:56.52 |
| kens | Robin_Watts : and/or tor8 I've got a local branch, and I want to pull into it the latest code from the master branch, how do I do that ? | 08:57.28 |
| tor8 | #define fz_for_each_text_span(line, block) for(line=block->lines; line < block->lines + block->len; line++) | 08:57.59 |
| Robin_Watts | kens: First, bring your local copy of master up to date. | 08:58.08 |
| kens | It is | 08:58.14 |
| tor8 | #define fz_for_each_text_style(style, sheet) for(style=sheet->stiles; style; style=style->next) | 08:58.28 |
| | etc... | 08:58.30 |
| Robin_Watts | Then change to your local branch, and rebase it on master. | 08:58.36 |
| kens | OK thanks | 08:58.42 |
| Robin_Watts | git checkout fred | 08:58.46 |
| tor8 | hides the implementation details of whether it's a list or array | 08:58.46 |
| Robin_Watts | git rebase master | 08:58.55 |
| kens | yes, that's the step I couldn't figure out thanks Robin_Watts | 08:59.08 |
| tor8 | Robin_Watts: but in trying that, I ran into the array-of-pointers with the spans... | 09:00.37 |
| | any special reason they're an array pointers rather than just a linked list? | 09:01.12 |
| | Robin_Watts: we could take the BSD queue.h stuff and fitz-ify it and use those macros everywhere we have our linked lists. it'd be a big project to revamp everything but it could end up fairly neat. | 09:02.20 |
| | and it buys us a good implementatio of double-linked lists | 09:02.38 |
| paulgardiner | And grab snprintf and family while you're there | 09:07.07 |
| Robin_Watts | tor8: I'm sure there was a reason. I can't remember offhand why now. | 09:20.45 |
| | Macros for linked lists are a bad idea. | 09:20.55 |
| tor8 | Robin_Watts: why do you think they are a bad idea? | 09:23.45 |
| Robin_Watts | Their cost outweighs their utility. | 09:28.30 |
| | They are invariably unreadable and confusing. | 09:29.11 |
| tor8 | for singly-linked lists I agree 100% | 09:29.51 |
| | doubly-linked lists, less os | 09:30.01 |
| Robin_Watts | tor8: There is a review for you on robin/master. | 09:48.31 |
| | Sebras pointed out a file we were very very slow on from sumatras bug database. | 09:48.57 |
| tor8 | Robin_Watts: so catching a small corner between tiles could mean running 4 times, but the whole area is still less than one tile? | 09:52.29 |
| | not sure that we need the 0.001 fudge factor in that variant | 09:53.01 |
| | that's basically there to prevent rounding errors causing a full tile draw for a sliver of a row/column on the edge | 09:54.36 |
| Robin_Watts | tor8: exactly. | 10:05.30 |
| | and yes, you may be right in that the 0.001 isn't needed. | 10:05.39 |
| | BUT... the 0.001 was being counted into the calculation of x0/x1/y0/y1, so I deliberately didn't want to change that. | 10:06.03 |
| tor8 | Robin_Watts: one fudge factor for the if-test (so that 1.001 tiles still count as one) | 10:06.43 |
| | another fudge factor for the floor/ceil later down | 10:06.53 |
| | would make it clearer I think | 10:06.57 |
| | (also, would you PLEASE add some blank lines in your code? paragraphs are useful, even in code...) | 10:07.22 |
| Robin_Watts | tor8: New version online now. | 10:10.43 |
| tor8 | fx1-fx0 >= 1? won't that make just a single tile also invoke the tile caching? | 10:12.16 |
| Robin_Watts | yes. Let me make it > | 10:13.18 |
| tor8 | I'd recommend 1.001 for the same reason as below | 10:14.02 |
| | well, maybe not | 10:14.14 |
| Robin_Watts | I'd be more tempted by a smaller number. | 10:14.25 |
| tor8 | since it depends on the size of the tile | 10:14.32 |
| Robin_Watts | new version on line. | 10:14.33 |
| tor8 | hm, maybe it was better as it was | 10:14.40 |
| Robin_Watts | If it's = 1 then we'd rather do it with no tiling. | 10:15.29 |
| tor8 | I mean leaving the 0.001 at the fx0 calculation | 10:15.50 |
| Robin_Watts | I can put it back if you'd rather. | 10:16.08 |
| tor8 | hm, no, that's not any better | 10:16.09 |
| | that's also just an arbitrary number depending on the tile size | 10:16.32 |
| | what we have now should be good, but maybe add a largish fudge factor for the if test | 10:16.56 |
| | if we find it helps. | 10:17.03 |
| Robin_Watts | The way it is now, it's an arbitrary epsilon that can't ever produce an antialiased difference. | 10:17.15 |
| tor8 | maybe 1.1 or 1.25 or something obviously big | 10:17.17 |
| Robin_Watts | And I feel that the "1" can be replaced by 0.8 or something, but shouldn't be replaced by anything higher than 1. | 10:17.54 |
| tor8 | I should just shut up and try to understand what you're doing in the "Merge line into prev_line" section | 10:17.59 |
| Robin_Watts | I'm pulling lines into paragraphs. | 10:18.33 |
| | And I'm also going for a run :) | 10:18.41 |
| | Are you happy with the tiling thing then? Or do you want to let it settle on you for a bit ? | 10:19.05 |
| tor8 | pulling them into in reverse order, gating on some column value | 10:19.07 |
| | I'm okay with the tiling | 10:19.15 |
| | not entirely convinced the if should be strictly 1.0 though | 10:19.44 |
| Robin_Watts | we can tweak it if we find a case where it matters. | 10:20.09 |
| Aneel | Hello there! | 11:34.43 |
| Robin_Watts | Aneel: hi. | 11:38.34 |
| Aneel | Hi Robin | 11:38.52 |
| | Am using MuPDF for one of my apps and need more details on the commercial lines.. | 11:39.18 |
| | a mail is sales would be the best way ? | 11:39.28 |
| Robin_Watts | Aneel: Absolutely. | 11:39.34 |
| Aneel | **license | 11:39.36 |
| | great thanks Robin | 11:39.45 |
| Robin_Watts | We stay out of the commercial side. | 11:39.52 |
| Aneel | okie | 11:40.05 |
| Robin_Watts | If you mail Scott, he'll mail you back a big scary list of questions. | 11:40.07 |
| | Answer it as best you can - it's just so he can get an idea of what you want to do. | 11:40.56 |
| Aneel | sure got it | 11:41.18 |
| henrys | kens:so I assume the other characters work because they are so large they are treated as a path and cached intellifonts don't work? | 12:50.18 |
| kens | henrys, all the characters in 23-15 work at low reoslution, as the resolution increaes the large charatcers stop working | 12:50.50 |
| | (this is in GS of course) | 12:51.33 |
| | acrobat works at all resolutions | 12:51.40 |
| | Or do you mean the other files ? 14-09 adn 19-10 ? | 12:52.52 |
| henrys | kens:the problem I saw was one character had a solid file and the others used the pattern. Same font, why would it differ for one character? | 12:53.25 |
| kens | henrys I don't know, I just treated the problem :-) | 12:53.48 |
| | I'd guess the large glyphs were uncached though | 12:54.06 |
| | Certainly all the working glyphs were drawn as paths, the non-woring one as a series of rectangles | 12:54.25 |
| henrys | Robin_Watts:did you see the following finale? | 12:56.26 |
| Robin_Watts | henrys: Tonight, I think. | 12:56.52 |
| | Yes, tonight. When was it shown in the states? | 12:57.24 |
| henrys | fox airs it monday night | 12:58.04 |
| Robin_Watts | right, so we're 24 hours or so behind. | 12:58.16 |
| | same as for GoT. | 12:58.20 |
| henrys | kens:I'll look at the changes now. | 12:58.34 |
| kens | THANKS HENRYS | 12:58.40 |
| Robin_Watts | Sky seem to have cottoned onto the fact that if they don't show stuff fast, people just torrent it. | 12:58.42 |
| henrys | kens:I believe microtype and intellifont are different. In fact the resident postscript fonts in a UFST build are micro type what font type does chrisl use for those? | 13:03.31 |
| | but the change seems right to me. I guess the micro type confusion was around before your change. | 13:08.24 |
| | kens ^^^ | 13:08.31 |
| kens | Oops sorry, wasn't paying attention | 13:08.43 |
| | henrys, I added several kinds of fonts to pdfwrite from PCL, but not Microtype, certainly I didn't add ther enum | 13:09.23 |
| | I thinkits better to process MT fonts as type 3 fonts for pdfwrite, as we get teh benefits of a proper font, so smaller files and text is (possibly) searchable | 13:10.16 |
| henrys | kens:I agree, yes | 13:10.50 |
| kens | I thought MicroType was a later development of Intellifont, but I could easily be msitaken | 13:11.08 |
| henrys | kens:I'm not clear on the history either. | 13:11.55 |
| Robin_Watts | henrys: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2673798/ | 13:22.42 |
| | paulgardiner, et al: http://ghostscript.com/~robin/MuPDF-17.apk <- Fixed version. | 13:25.07 |
| paulgardiner | Robin_Watts: yes, works for me. | 13:27.47 |
| henrys | Robin_Watts:ah yes somebody in the program mentioned this would be the next step, to just look at protein restriction. | 13:29.38 |
| | Robin_Watts:there was a recent study with primates showing no life extension but aging disease protection - the other part of this is evidence of neurogenises when you fast. | 13:32.10 |
| paulgardiner | At last!!!! I have a successful call to gs from my WinRT test app. | 13:55.14 |
| henrys | paulgardiner: wow yeah! | 13:55.31 |
| paulgardiner | It's only a call to gapi_revision, but with some luck the other entry points would now work. | 13:57.37 |
| kens | THe first one is the hard one... | 13:57.55 |
| paulgardiner | I hope you're right. | 14:01.04 |
| Robin_Watts | paulgardiner: Excellent! | 14:05.57 |
| | paulgardiner: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=2df69b18472d6ac1989209377916093878317faa | 14:15.50 |
| henrys | I wish tkamppeter could do something about not using the shared libraries. The advantages to using tested software must certainly outweigh any benefits of the shared libs. Another crash lcms2 this time. | 14:18.28 |
| kens | Yes, and it doesn't happen if you use our libraries.... | 14:18.48 |
| henrys | of course not, we wouldn't have shipped a crash in chess.ps it's tested. | 14:19.50 |
| kens | QAuite, I meant that the problem should therefore have been obvious to the user.... | 14:20.17 |
| henrys | Robin_Watts:sigh only 6 people in the study, not a convincing sample I hope they do more research. | 14:23.49 |
| paulgardiner | Robin_Watts: looks fine. | 14:25.19 |
| Robin_Watts | paulgardiner: Thanks | 14:25.56 |
| tor8 | Robin_Watts: a few patches on tor/rtl | 14:34.16 |
| Robin_Watts | looking now. | 14:34.50 |
| tor8 | the first UCDN one can be skipped for now | 14:35.21 |
| Robin_Watts | tor8: Ah, I was just looking at that. | 14:37.15 |
| | The UCDRecord could probably be shrunk. | 14:37.34 |
| | by using bitfields, rather than unsigned char's. | 14:37.44 |
| | category is 5 bits for example. | 14:37.52 |
| | bidi class is 5 bits. | 14:38.48 |
| | mirrored is 1 bit. | 14:39.00 |
| | scripts is 7. | 14:40.18 |
| tor8 | can you get it down to 4 bytes is the question, or alignment says hello. also, bitfields are scary. | 14:41.15 |
| Robin_Watts | tor8: I'm sure it can be got down to 4 bytes. | 14:41.38 |
| | the device hint stuff looks sensible. | 14:41.48 |
| henrys | chrisl:when you say get rid of macros, it goes to p1 in my brain - 693934 | 14:42.48 |
| Robin_Watts | The split looks sensible, though... do we have a policy of all device classes being dev_xxx.c ? Probably not with draw/draw_device.c. | 14:42.58 |
| | tor8: I liked the fact that normalise was static inline. | 14:43.31 |
| | can we move it to fitz.h as a static inline ? | 14:43.47 |
| tor8 | no policy about that | 14:43.54 |
| chrisl | henrys: yeh, that's a mother of macro and does some truly horrific things - like, really bad practice type things! | 14:44.21 |
| tor8 | there's a lot of functions that could benefit from inclusion in fitz.h as static inlines. I'd prefer to keep it slim and only let in the ones that live in inner loops end up there. | 14:44.40 |
| Robin_Watts | tor8: Well, the normalise vector gets called once per char, I think. | 14:45.09 |
| | twice per char, even. | 14:45.23 |
| | but it's not the end of the world I guess. | 14:45.47 |
| tor8 | and the bbox union stuff gets called at least as often :) | 14:45.55 |
| | we could do a benchmark once by moving all those tiny utility functions into a fitz-inline.h header | 14:46.18 |
| Robin_Watts | tor8: A fitz-inline.h sounds nice. | 14:46.34 |
| | separates the API from the implementation. | 14:46.46 |
| tor8 | and see if the code bloat cache misses outweigh the function call overhead | 14:46.50 |
| | yeah. a fitz-inline.h would be nice now that you mention it. | 14:47.37 |
| Robin_Watts | I'm happy enough with those 3 (or even 4) as is. | 14:47.38 |
| tor8 | or finally do that split the headers into a bazillion pieces | 14:47.49 |
| Robin_Watts | want me to pull/push stuff ? | 14:47.59 |
| | How much space does the UCDN thing take ? | 14:48.30 |
| tor8 | the .o is 100k | 14:49.06 |
| | the ucdrecord is actually pretty small, only a few hundred entries | 14:49.20 |
| Robin_Watts | so, not too bad. | 14:49.33 |
| tor8 | the UCDN thing is missing makefile stuff for android and win32 | 14:49.41 |
| henrys | Robin_Watts:does the bugzilla CLA give email instructions? | 14:50.03 |
| Robin_Watts | so I'll leave that one for a mo. | 14:50.03 |
| | http://bugs.ghostscript.com/attachment.cgi?id=9346 | 14:51.04 |
| tor8 | I've got an experimental patch to turn the line->span into a linked list. but I'm at a loss trying to understand what you do when merging lines in the paragraph analysis step. | 14:51.17 |
| Robin_Watts | tor8: Let me pull/push your stuff, then I'll be in the same state you are. | 14:51.46 |
| | ok, pushed. So what line of what file are you confused at? | 14:57.48 |
| | or should we wait until after the meeting? | 14:57.55 |
| tor8 | text_paragraph.c the section between "Merge line into prev_line" and "Leave line empty" | 14:59.06 |
| henrys | ah meeting time | 14:59.53 |
| Robin_Watts | tor8: will postpone til after the meeting. | 15:00.08 |
| tor8 | Robin_Watts: let me push an in-progress patch and you can look after the meeting | 15:00.13 |
| Robin_Watts | ok. | 15:00.18 |
| tor8 | Robin_Watts: on tor/rtl now | 15:00.49 |
| henrys | seems like we should do winrt discussion at the gs meeting. | 15:01.07 |
| | paulgardiner: will you be around in an hour? | 15:01.19 |
| Robin_Watts | henrys: Internationalisation done, pushed to Google Play. But I broke text selection while doing it. That's fixed, and waiting for that to publish now. | 15:01.30 |
| henrys | Robin_Watts:wow fast work. | 15:01.56 |
| Robin_Watts | The internationalisation was fairly easy. OneSkyApp seems to work well. | 15:02.29 |
| paulgardiner | henrys: yes, but will need to go after about 1/2 h | 15:02.51 |
| Robin_Watts | Of course, we'll now get complaints that the hungarian version is telling people that their hovercraft is full of eels, but... | 15:03.02 |
| mvrhel_laptop | good morning | 15:04.01 |
| Robin_Watts | Morning | 15:04.06 |
| henrys | Robin_Watts:I would think all of it would be fairly boilerplate and common to many apps | 15:04.08 |
| | hi mvrhel_laptop | 15:04.25 |
| Robin_Watts | henrys: Indeed. It's all automatic once you add the right values/strings.xml files. | 15:04.37 |
| tor8 | Robin_Watts: "reflow" seems to have been most problematic when translating | 15:04.50 |
| Robin_Watts | yeah. Also "strikeout" and "ink" | 15:05.12 |
| | Customer 530 seems happy again (famous last words). | 15:05.23 |
| henrys | let's not worry about reflow until we get complaints. | 15:05.38 |
| Robin_Watts | Scott has a potential new customer on the line that wants to use us as part of a digital signage thing. | 15:06.00 |
| henrys | we have to give them some reason to learn english ;-) | 15:06.02 |
| tor8 | we've got a slow-but-working new triangle mesh rasterizer that seems to solve most pixel gaps in the meshes | 15:06.02 |
| Robin_Watts | They claim that we leak. We certainly *did* leak, and I've fixed that (we now have a memento build for android). | 15:06.39 |
| | They claim we still leak, but they have failed to produce any evidence of it. | 15:06.59 |
| | so we'll wait to see what they come back with. | 15:07.08 |
| henrys | OH I didn't realize they were a signage company, interesting | 15:07.12 |
| Robin_Watts | They have extended the android MuPDF viewer with their own ImageView.class thing. | 15:08.00 |
| | I do wonder if we can't do that better by just adding simple PNG/TIFF/JPEG recognisers in mupdf directly. | 15:08.28 |
| | That's only a day or so's work, I reckon. | 15:08.36 |
| henrys | do we see any issue with still meeting the broad outline of the schedule we gave miles, Robin_Watts and tor8 had milestones in that. | 15:08.40 |
| Robin_Watts | henrys: I have image extraction working, but nothing smart about reordering images within the text. | 15:09.23 |
| henrys | Robin_Watts: and doing pdf wrappers? | 15:09.40 |
| Robin_Watts | I'm very tempted to just ignore that until we actually get some comments back. | 15:09.47 |
| | pdf wrappers? | 15:09.50 |
| tkamppeter | henrys, crash caused by lcms2? Is there a bug report? | 15:10.10 |
| henrys | jpeg -> pdf or render jpeg directly? | 15:10.19 |
| Robin_Watts | MuPDF currently handles 3 input formats, PDF, XPS, CBZ. | 15:10.23 |
| | I'm proposing we add some more, JPEG, PNG, TIFF. | 15:10.33 |
| | All the hard stuff is done for that. It's just some stub functions and code to call the device is required. | 15:11.03 |
| | i.e. no extra code inside the core devices/renderer is required. | 15:11.59 |
| henrys | Robin_Watts:the ghostscript solution to that was to create a postscript program that converted that to a ps image - I imagine you could do something similar in mupdf with pdf instead of postscript | 15:12.05 |
| tkamppeter | henrys, GS in Ubuntu 13.04 uses the built-in lcms2 due to an API incompatibility. | 15:12.06 |
| Robin_Watts | henrys: but why bother? That'd be way harder. | 15:12.24 |
| henrys | tkamppeter: 693942 | 15:12.43 |
| Robin_Watts | henrys: That approach makes sense with gs, but not so much with mupdf. | 15:13.33 |
| kens | agrees | 15:13.44 |
| | Its gfine wghen you already have a programming language | 15:13.57 |
| Robin_Watts | Going back to the potential customer and their leaks... they claim that it's android Bitmaps leaking. | 15:14.09 |
| henrys | Robin_Watts: right it makes sense in gs because it is difficult to support all the options and stuff in a new language. Everything just works, to this day PCL doesn't support everything - arrays dictionaries etc. | 15:14.27 |
| paulgardiner | Robin_Watts: so just a few more fz_document virtual function collections? | 15:14.30 |
| kens | henrys that bug report doesn't say its Ubuntu does it ? | 15:14.37 |
| | (the LCMS2 one) | 15:14.52 |
| henrys | kens:no it doesn't just linux | 15:14.56 |
| tor8 | paulgardiner: yeah. | 15:14.58 |
| Robin_Watts | paulgardiner: Exactly. | 15:15.00 |
| paulgardiner | Almost rude not to. | 15:15.11 |
| henrys | tor8:how are you schedule wise? | 15:15.12 |
| kens | henrys, well I guess we cna't hold Till's feet to the fire for anything except Ubuntu | 15:15.15 |
| tor8 | essentially mucbz without the zip file handling | 15:15.25 |
| Robin_Watts | They have yet to make their case for that, but if it *does* turn out to be Android having a hard time gcing Bitmaps, then it may be worth us revisiting the Bitmap handling. | 15:15.27 |
| | and by "us" I mean "paulgardiner" :) | 15:15.39 |
| | also, we might want to do "image directories" too. | 15:16.25 |
| | mucbz without the zipfiles. | 15:16.32 |
| paulgardiner | which I'd be quite keen to do because there really should be a way to avoid bitmap churn | 15:16.33 |
| tor8 | henrys: been banging on RTL reordering. I've found and integrated a unicode character database thing into the library. | 15:16.58 |
| tkamppeter | henrys, problem does not occur in Ubuntu 13.04 as the internal liblcms2 is used. | 15:17.49 |
| henrys | the final item for mupdf'ers is a schedule for read for writing svg, shall we tell him we are still in research mode? We should say something. | 15:18.40 |
| | sorry schedule for Raed for writing svg | 15:19.06 |
| | tricky | 15:19.15 |
| Robin_Watts | henrys: I'd like to try that. | 15:19.18 |
| | If we can safely park the image extraction stuff, then I can try to bash something out on that. | 15:19.45 |
| henrys | Robin_Watts:fine by me. tell marcosw what to tell Raed now - schedule wise. | 15:20.57 |
| Robin_Watts | Tell him we're trying for a solution now. More information (possibly just a more accurate schedule) in a couple of weeks. | 15:21.28 |
| henrys | tkamppeter: internal? do you mean the gs version? | 15:22.00 |
| | Robin_Watts: okay I'll pass that on to marcosw | 15:22.29 |
| | maybe he is here | 15:22.39 |
| Robin_Watts | tkamppeter: Is there any reason (other that dogma) why they cannot use our internal lcms2? | 15:23.10 |
| henrys | anything else, mvrhel_laptop viewer stuff to discuss? | 15:23.13 |
| Robin_Watts | The code, as supplied by us works fine. They bent it, they broke it, they get to fix it, IMHO. | 15:23.29 |
| mvrhel_laptop | henrys: no. I have pulled out the rendering and mupdf stuff into a winrt component. my viewer code is in disarray though but I am hoping to have it back together by the end of this week | 15:24.15 |
| henrys | mvrhel_laptop: the business of putting everything in a winrt object sort of made me think of lack of code sharing amonst platforms but I don't know enough about the code to know if that is a legitimate concern | 15:24.34 |
| mvrhel_laptop | henrys: yes. that part of the code is pretty small actually | 15:25.04 |
| Robin_Watts | henrys: Putting everything into a winrt object presumably packages a fairly high level interface in a winrt specific way. | 15:25.26 |
| | It may be that that particular high level interface is similar on all platforms. | 15:25.41 |
| mvrhel_laptop | i just have a few simple calls, with the rendering calls wrapped up so that they launch as async tasks | 15:25.43 |
| | in different threads | 15:25.48 |
| | that all seems to be working nicely | 15:26.11 |
| | fighting a dumb xaml data binding issue which will make my zooming work better | 15:26.35 |
| | so that I can zoom directly in the flip view | 15:26.50 |
| | and not have the separate canvas like I had | 15:27.02 |
| henrys | okay I am sure the review process will catch any of my concerns. seems important that paulgardiner keep up with your code so you are both sort of steering in the same direction on Android and Windows | 15:27.06 |
| mvrhel_laptop | henrys: fair enough. I will try to get this all back together this week. | 15:27.36 |
| | i really dont want to work on a lcms 2 external library call problem... | 15:28.10 |
| kens | sI don't believe that's our problem. It works if you use our version of the library.... | 15:28.54 |
| | I'd close it as invalid or wontfix | 15:29.16 |
| Robin_Watts | kens: I *believe* that we've passed everything back to Marti. | 15:29.17 |
| | and he's taken almost everything on. | 15:29.30 |
| kens | Robin_Watts : but which version of LCMS2 is the reporter using ? | 15:29.33 |
| Robin_Watts | kens: right, so they are out of date. | 15:29.51 |
| chrisl | The next version (with our fixes) won't appear for a couple of months yet, IIRC | 15:29.58 |
| kens | Robin_Watts : exactly | 15:30.02 |
| | so not our problem.... | 15:30.07 |
| Robin_Watts | chrisl: It's in git now. | 15:30.28 |
| chrisl | Robin_Watts: but not in a versioned release | 15:30.40 |
| Robin_Watts | actually, there are 3 outstanding patches. I'll mail him again. | 15:30.47 |
| | all mem squeeze fixes. | 15:30.58 |
| henrys | chrisl:so can we just send him back to his distribution. | 15:31.18 |
| | and close the bug. | 15:31.24 |
| mvrhel_laptop | ok. so everyone is fine with Invalid? | 15:31.25 |
| chrisl | henrys: I feel that's the right course, yes | 15:31.39 |
| kens | Sounds good to me yes | 15:31.49 |
| henrys | mvrhel_laptop: wont fix go back to your distributor | 15:32.12 |
| | I can do it if you want, yoiu have the assignment I guess. | 15:32.52 |
| mvrhel_laptop | henrys: done | 15:35.53 |
| henrys | thanks | 15:36.04 |
| mvrhel_laptop | i like fixing those kinds of bugs | 15:36.18 |
| Robin_Watts | Anything else for the mupdf meeting? | 15:37.32 |
| | If not, we could either do the winrt stuff now, or I can talk to tor8 about the paragraph analysis code. | 15:38.22 |
| paulgardiner | That's fine with me. | 15:39.57 |
| tor8 | Robin_Watts: the analysis code question is not in a hurry | 15:43.46 |
| henrys | tkamppeter: I notice you have quite a few valgrind bugs in bugzilla - do you know about those? I don't know how well you keep up with our bugzilla stuff. | 15:45.53 |
| marcosw_ | kens: thanks for you analysis of the N.PS file; I've emailed the customer. | 15:57.27 |
| kens | No problem | 15:57.34 |
| henrys | I meant to bring up 693719 at the mupdf meeting - is that something that can be bountied to zeniko? | 15:58.43 |
| | and another meeting | 15:59.33 |
| kens | Hmm, that hour went fast | 15:59.57 |
| henrys | paulgardiner has been working on the winrt stuff⦠curious how he like the gs makefiles ;-) | 16:00.19 |
| | I think mvrhel_laptop is the only other staffer using even windows 8 | 16:01.06 |
| paulgardiner | Luckily I've had to mess with only one of them so far | 16:01.20 |
| kens | I have Windows 8 instgealled, btu I'm not using it | 16:01.29 |
| Robin_Watts | UKers: http://uk.nook.com/ | 16:01.42 |
| mvrhel_laptop | i have drunk the kook-aid and all is fine | 16:01.48 |
| | kool-aid | 16:01.53 |
| kens | kook-aid sounds more like it | 16:02.12 |
| henrys | kens:my kids like 8 but they might have different criteria, they'd probably prefer a desktop phone. | 16:02.16 |
| mvrhel_laptop | yes... | 16:02.18 |
| alexcher | marcosw: the file can be fixed by changing 32 to 320 in a few places. | 16:02.41 |
| kens | Robin_Watts : but that assumes I want a Nook at any price... | 16:03.08 |
| Robin_Watts | kens: indeed. I passed for the same reason, but I thought I'd mention it. | 16:03.25 |
| henrys | I went through the bug list before the meetings today, the valgrind stuff is overwhelming. | 16:03.26 |
| marcosw_ | henrys: and I haven't entered the valgrind fuzzing results. Those are even worse. | 16:04.46 |
| henrys | can everyone please watch out for paulgardiner weekly status report and check if you can help. | 16:04.52 |
| | ? | 16:04.53 |
| | normally his status is for mupdf folks but he's working on gs now. | 16:05.14 |
| paulgardiner | I do have a few questions. | 16:05.43 |
| henrys | paulgardiner: shoot | 16:05.54 |
| | marcosw_:a PACIFY_VALGRIND run would make at least a few of these go away | 16:06.22 |
| marcosw_ | alexcher: thx, but I think we've done all we need to do, we don't want to get into the habit of hand fixing bad PostSrcript files. | 16:06.47 |
| paulgardiner | In some of the windows specific files I've needed to avoid some windows apis that are not allowed under Winrt. Some have good alternatives, but in others I've had to break things, and I'm wondering how broken I've made them. | 16:07.03 |
| henrys | marcosw_:I saw a couple of support issues that need to be dispatched should we do that now or do you want to do it later? | 16:07.08 |
| marcosw_ | henrys: we can do it now | 16:07.39 |
| chrisl | paulgardiner: best thing to do there is push the changes to your own git repo, and let us all have a look and a play. | 16:07.59 |
| henrys | paulgardiner:others may want to weigh in here but I guess we are going to need a collection of gp_* files for winrt. | 16:08.23 |
| paulgardiner | There are only three problem areas, and you may know what effect the changes will have immediately. Probably worth going through them | 16:09.12 |
| henrys | all please try and look at a few valgrind problems when you have a chance. Mine were fairly easy and one was really worth fixing. | 16:09.33 |
| paulgardiner | I've hardwired gp_open_scratch_file to return NULL. Wondering if gs will still limp along without that. | 16:10.07 |
| ray_laptop | paulgardiner: are the three problem areas mentioned in your email (I didn't read it yet) ? | 16:10.08 |
| | paulgardiner: um, not very well. | 16:10.27 |
| paulgardiner | ray_laptop: no I don't think I listed them there. | 16:10.29 |
| kens | I think I did all my valgrind problems already | 16:10.29 |
| chrisl | henrys: you were lucky then - three out the four valgrind bugs I fixed were really horrid :-( | 16:11.01 |
| ray_laptop | gp_open_scratch_file is used for clist temp files and pdf temp files (iirc) | 16:11.04 |
| paulgardiner | Okay, there is a work around for the scratch file, it's just a but messy. I was hoping to be able to test gs to some degree without doing so, but... | 16:11.22 |
| ray_laptop | paulgardiner: for clist, we can use the BandListStorage=memory | 16:11.33 |
| | but I don't think pdfwrite will run at all | 16:11.58 |
| chrisl | paulgardiner: surely there must be a standard way to get a temp file object in winrt? | 16:12.06 |
| Robin_Watts | paulgardiner: When rendering to a bitmap at low res, gs devices tend to run in page mode (hold the whole thing in memory as a bitmap). For higher res things,we render to a display list (aka command list aka clist). | 16:12.08 |
| kens | No, pdfwrite *requires* temporary files | 16:12.09 |
| ray_laptop | kens: well, you _could_ re-write pdfwrite to use the 'memfile' io functions | 16:12.38 |
| Robin_Watts | clist files can be written as temporary files on disc, or held in memory (as ray_laptop has already aluded too) | 16:12.40 |
| kens | ray_laptop : maybe, but it would be a lot of work | 16:12.53 |
| kens | feels sure there must be some method of opening a file | 16:13.15 |
| Robin_Watts | paulgardiner: You absolutely can *test* gs without having scratch files. | 16:13.16 |
| henrys | mvrhel_laptop, ray_laptop, Robin_Watts seem to have the bulk of the open problems. | 16:13.17 |
| ray_laptop | clist files in memory used to be a compile time option, but now it is a run-time parameter | 16:13.18 |
| Robin_Watts | Just keep the resolution down and don't use pdfwrite, and you'll be fine. | 16:13.43 |
| henrys | does raed need pdfwrite - not to say we shouldn't fix this but do we need it now? | 16:14.07 |
| paulgardiner | Okay good. That was what I wanted to know. So I can test without it, but a customer is not likely to get far without it. | 16:14.11 |
| Robin_Watts | right. | 16:14.19 |
| henrys | paulgardiner: so 2 more? | 16:14.45 |
| paulgardiner | Problem 2: | 16:14.52 |
| | in gp_local_arg_encoding_get_codepoint. | 16:15.12 |
| Robin_Watts | oh, I wrote that :( | 16:15.55 |
| paulgardiner | There is no IsDBCSLeadByteEx, so I've changed the test to if(0) which I think will work for ascii but not general utf8. | 16:16.04 |
| | Problem 3: | 16:17.04 |
| ray_laptop | kens: actually, it probably wouldn't be too hard. There's fopen, fclose, fwrite_chars fread_chars, ftell, fseek, rewind, unlink. You probably don't need more than that. Note fseek and ftell are int64_t offset | 16:17.08 |
| kens | paulgardiner : said he had a work-around ray_laptop | 16:17.23 |
| Robin_Watts | http://msdn.microsoft.com/en-us/library/windows/desktop/hh802935(v=vs.85).aspx | 16:17.54 |
| mvrhel_laptop | that is desktop app stuff | 16:18.21 |
| paulgardiner | I've had to hardwire paper to "letter" because there is no GetLocalInfo. | 16:18.23 |
| chrisl | paulgardiner: jeez, you could have used a4 ;-) | 16:19.01 |
| paulgardiner | chrisl: :-) | 16:19.11 |
| henrys | I didn't think ghostscript depended on locale thought there was already a fallback for paper. | 16:19.51 |
| | and it was letter | 16:20.00 |
| ray_laptop | and -sPAPERSIZE is command line (along with the DEVICEWIDTH/HEIGHT options and -g) | 16:20.40 |
| henrys | kens:it doesn't seems paulgardiner change is a workaround exactly - as noted the customer won't get far. | 16:20.47 |
| Robin_Watts | paulgardiner: WinRT has no concept of codepage, AIUI. It's all unicode. | 16:21.10 |
| paulgardiner | henrys: I have a better work around. Just haven't done it yet. | 16:21.13 |
| henrys | paulgardiner: oh okay. | 16:21.24 |
| ray_laptop | there has to be a way to handle temp files ! | 16:21.32 |
| paulgardiner | Robin_Watts: yes that seems to be the case. I had to use ExW versions of thing in several places | 16:21.49 |
| marcosw_ | henrys: did you see the email from the consultant working with customer 396? he'd like to schedule a phone call to discuss issues with their driver and DeviceN color space. The subject is "problem with certain PDF files and general support". Do you prefer if ray_laptop or mvrhel_laptop speaks with them. | 16:21.49 |
| Robin_Watts | gp_local_arg_encoding_get_codepoint is only called if we have encoding == GS_ARG_ENCODING_LOCAL | 16:22.25 |
| paulgardiner | It's okay. There is a way to handle temp files. I was just asking about it wondering how well gs would limp along wthout them until I bit the bullet | 16:22.36 |
| henrys | ray_laptop usually does that but I don't feel strongly one way or the other. | 16:22.41 |
| Robin_Watts | and for metro we should probably make GS_ARG_ENCODING_LOCAL mean UTF8. | 16:22.44 |
| paulgardiner | Robin_Watts: right. That sounds good | 16:23.18 |
| marcosw_ | henrys: okay, ray_laptop was my first choice. thx. | 16:23.21 |
| Robin_Watts | paulgardiner: see iapi.c line 277 | 16:23.28 |
| | #if defined(__WIN32__) | 16:23.38 |
| henrys | marcosw_:look above for Robin_Watts response to Raed. | 16:23.45 |
| Robin_Watts | Hopefully that should be false? | 16:23.52 |
| henrys | marcosw_693853 should go to chrisl | 16:24.10 |
| Robin_Watts | Maybe we just need to wrap gp_local_arg_encoding_get_codepoint in the same #ifdef ? | 16:24.11 |
| henrys | alexcher:693731 needs a comment | 16:24.39 |
| ray_laptop | marcosw: should Miles be aware of shearwater ? i.e. does their shipment get counted in cust 680's numbers. Also, cust 680 is marked "ZERO" support in Joann's list | 16:26.14 |
| marcosw_ | henrys: I found it: "More information (possibly just a more accurate schedule) in a couple of weeks." | 16:26.18 |
| Robin_Watts | paulgardiner: So it sounds like you can make progress right? (The half hour is approching) | 16:26.20 |
| paulgardiner | Yes thanks | 16:26.31 |
| henrys | marcosw_: and 693847 needs followup - I'm not sure if that is a form thing that might work in some mupdf variant - alexcher didn't give a detailed explanation. | 16:26.44 |
| alexcher | henrys: yes, a comment is easy. Fixing annotations without appearance streams is more difficult. | 16:26.55 |
| ray_laptop | so a non-customer distributing the products of a customer that gets no support doesn't sound like we should be involved | 16:27.05 |
| pgogna | Robin_Watts: For double tap to zoom feature. I am able to zoom the pdf according to rect but it is not scrolling appropriately to keep the rect in the center of the page. | 16:27.37 |
| ray_laptop | henrys: do you want to clarify this with Miles BEFORE we give them more support ? | 16:27.45 |
| Robin_Watts | pgogna: OK, so you've got the zoom working, but you're not updating the X/Y of the page ? | 16:28.10 |
| henrys | ray_laptop:I'm sorry what problem are we talking about? | 16:28.14 |
| alexcher | henrys: The file requires JavaScript and a proprietary decoder. gs cannot do either one. | 16:28.41 |
| pgogna | Yes this is the problem | 16:28.47 |
| | I tried to do that but it is not correct always | 16:29.08 |
| marcosw_ | ray_laptop: sorry, you are right, i didn't realize 680 was zero support. I'll forward the email to miles. | 16:29.16 |
| henrys | alexcher:we have some javascript support in mupdf obviously the proprietary encoder won't work | 16:29.39 |
| Robin_Watts | pgogna: From a quick look at the source it's PageView.java you should be working in, right? | 16:30.36 |
| ray_laptop | marcosw: OK. Thanks. | 16:31.02 |
| henrys | right zero support go back to miles - I would be inclined to tell the customer we can't help you until you talk to miles also but whatever you want to do. | 16:32.08 |
| ray_laptop | henrys: nm. Marcos is going to forward the shearwater question to Miles (although since he cc'ed "staff" Miles already got his email to Joann) | 16:32.13 |
| pgogna | No i am handling the double tap event in ReaderView.java as from here scale zoom is working. | 16:32.21 |
| Robin_Watts | pgogna: Where do you set the zoom? | 16:32.47 |
| henrys | alexcher:write up the status in the bug - we have no plans to implement javascript in gs - mupdf has some js support send it back to marcos⦠what else can you do? | 16:33.28 |
| Robin_Watts | pgogna: In ReaderView, I see places where it does the scale. | 16:33.46 |
| kens | OK I htink the meeting is over ? I'm heading off. Goodnight all | 16:33.48 |
| marcosw_ | kens: night | 16:33.54 |
| henrys | paulgardiner: certainly don't want to hold you up. | 16:34.00 |
| ray_laptop | marcosw: also, it looks as if Shearwater is doing development of products using the gs dll directly. They may not be aware of license issues at all, since new products that are developed won't be covered under the old cust 680 license | 16:34.06 |
| Robin_Watts | Look for "//Work out the focus point relative to the view top left" | 16:34.23 |
| paulgardiner | henrys: ta | 16:34.31 |
| alexcher | henrys: the bug 693847 is already assigned to Marcos. | 16:34.37 |
| Robin_Watts | There, mXScroll and mYScroll are updated to keep the area centred. You want to be doing the same kind of thing. | 16:35.03 |
| pgogna | Yes that is why i am working in this class and using the already written code to do my work | 16:35.04 |
| | but it is not working always | 16:35.14 |
| henrys | alexcher:I thought you were talking about your customer bug. | 16:35.18 |
| ray_laptop | oops. kens should be alerted as well to not support them (he answered their first round of questions) | 16:36.18 |
| Robin_Watts | pgogna: Well, you will clearly need to code it differently. | 16:36.38 |
| | You won't be scaling around the focus. | 16:36.52 |
| pgogna | In onScale it is updating it point by point by using detector.getScalingFactor() but here i have to scroll it to the end result | 16:37.48 |
| | Yes exactly | 16:38.07 |
| alexcher | henrys: Annotations without appearance streams can be coded eventually. I'd rather keep the bug 693731. | 16:38.27 |
| Robin_Watts | Well, you have the bbox of the paragraph, in the screen coords, at the current scale, right? Call that b0. | 16:38.55 |
| pgogna | Yes i had | 16:39.19 |
| Robin_Watts | and you have a scale factor that you are applying to bring b0 up to it's new size. | 16:39.33 |
| pgogna | yes | 16:40.08 |
| henrys | alexcher:well can we have an assigned status and a description of what needs to be done. | 16:41.07 |
| | ? | 16:41.08 |
| alexcher | henrys: yes | 16:42.18 |
| Robin_Watts | So b0.x0 = mXScroll + the real X position at the current scale. | 16:42.19 |
| ray_laptop | Robin_Watts: before I honk up my git repo, to interactively pull in revisions from my branch to the master, I would checkout master, then use git rebase -i mybranch ??? | 16:42.49 |
| Robin_Watts | ray_laptop: No. | 16:43.04 |
| | Think of the development tree. | 16:43.56 |
| | You have a new branch of development that forks off master at some point in the past. | 16:44.12 |
| | What you want to do is to 'rebase' that branch on master. | 16:44.24 |
| | i.e. you want to grab the base of that branch and slide it along master, leaving it sat at the tip of master. | 16:44.50 |
| ray_laptop | Robin_Watts: I do that frequently to keep my branch from getting 'stale' | 16:45.00 |
| Robin_Watts | Right. | 16:45.07 |
| | Once you have your development tree sat on the tip of master, you: git checkout master then git reset branchname. | 16:45.48 |
| pgogna | You want me to change the bbox to the current scale or the mXScroll value to scroll it | 16:45.57 |
| Robin_Watts | i.e you reset "master" to point at "branchname". | 16:45.58 |
| ray_laptop | ok, but when do I do the rebase -i ? when I am on the branch ? | 16:46.33 |
| Robin_Watts | pgogna: You need to adjust mXScroll as appropriate. | 16:46.37 |
| | ray_laptop: Why would you rebase -i ? | 16:46.49 |
| | rebase -i is for interactively altering the recent history of a branch. | 16:47.12 |
| ray_laptop | to squash and skip some commits | 16:47.14 |
| pgogna | this is what i need from you that how to calculate that value of mXScorr | 16:47.22 |
| | *mXScroll | 16:47.34 |
| ray_laptop | OK, so I rebase -i HEAD~6 (when on the branch that is 6 ahead of master) | 16:48.03 |
| Robin_Watts | ray_laptop: You have a choice (as always with git). | 16:48.15 |
| | You COULD change to your branch, then rebase -i HEAD~6 | 16:48.31 |
| | and you'll rewrite your branches history to be simpler. | 16:48.40 |
| | OR you could put your branch onto the end of master, move master to include that branch, and then rewrite it there. | 16:49.01 |
| ray_laptop | OK. That will let me do a clusterpush to make sure all is OK | 16:49.04 |
| Robin_Watts | which could potentially leave you with the long history in your branch (so you have a record of it), and the potted version on master. | 16:49.27 |
| | it's all down to what you prefer. | 16:49.33 |
| | pgogna: So you want me to do your thinking for you? :) | 16:49.55 |
| ray_laptop | I don't really need to long history, but I will reword some of the log messages | 16:50.09 |
| Robin_Watts | pgogna: Let me think for a mo. | 16:50.21 |
| | pgogna: So, do we have factor = mScale/previousScale as before ? | 16:51.07 |
| henrys | Robin_Watts:how did you come across the fasting article at NIH - I have a google scholar alert for fasting and it didn't' turn up? | 16:52.18 |
| Robin_Watts | henrys: A friend put it on facebook. | 16:52.36 |
| mvrhel_laptop | finally, I made some progress on this damn ui thing | 16:53.19 |
| | i was up until 2am with this last night | 16:53.32 |
| | so badly documented | 16:53.40 |
| Robin_Watts | henrys: someone pointed out that the paper dates from 2008/9 | 16:53.41 |
| pgogna | Robin_Watts: please help me a had close deadline to meet and i am completely stuck | 16:55.23 |
| | Yes we have factor = mScale/previousScale | 16:55.42 |
| Robin_Watts | OK, still trying to think this through. | 16:55.55 |
| | In general we have docspace_x + v.getLeft() - mxScroll = screen coord. | 16:56.56 |
| | No. | 16:57.17 |
| | In general we have docspace_x + v.getLeft() + mxScroll = screen coord. | 16:57.22 |
| | so the current code finds viewFocusX = screen coord - (v.getLeft() + mxScroll) | 16:58.21 |
| | and then it adjusts mxScroll by the difference between the old and new viewFocusX positions when scaled. | 16:59.32 |
| henrys | Robin_Watts:a more recent summary is here: http://www.ncbi.nlm.nih.gov/pubmedhealth/behindtheheadlines/news/2013-01-14-does-the-52-intermittent-fasting-diet-work-/ | 16:59.49 |
| Robin_Watts | So using the same thing, we find docspace_x = b0.x - (v.getLeft() + mxScroll); | 17:00.42 |
| | That's the left hand edge of our desired bbox in document space. | 17:00.59 |
| | and we want to scroll that to be at 0. | 17:01.11 |
| | so I think we want mxScroll += 0 - docspace_x * factor; | 17:01.29 |
| | pgogna: Try that. | 17:01.44 |
| pgogna | I am trying | 17:07.39 |
| | can you debug my code remotely? :) | 17:14.16 |
| Robin_Watts | pgogna: You say you are up against a deadline. What sort of deadline? | 17:14.36 |
| pgogna | I want to move to new project once I am done with this | 17:15.14 |
| Robin_Watts | Is this a college assignment? or is this something your boss is wanting ? | 17:15.17 |
| pgogna | I am trying to finish this for my friend actually. | 17:15.47 |
| Robin_Watts | I don't see how I can debug your code remotely. | 17:19.53 |
| pgogna | teamviewer? | 17:20.12 |
| Robin_Watts | If it's not working, we can try stopping it in the debugger, and capturing some values. | 17:20.20 |
| pgogna | Sure | 17:21.49 |
| ray_laptop | whoee. git rebase -i is my new favorite command. I even managed to have it squash two commits after I swapped the lines in the list. | 17:22.55 |
| Robin_Watts | ray_laptop: It is a lovely facility. | 17:23.28 |
| ray_laptop | Robin_Watts: thanks for your help (and encouragement) I always get nervous when trying something new on git 'cause I've honked up my repo too many times) | 17:24.33 |
| Robin_Watts | Is there a facility in gs to make it print the gid's of text that it encounters ? | 17:24.41 |
| | ray_laptop: np. | 17:24.45 |
| | I have a PDF here, that acrobat and gs get right. | 17:24.55 |
| | and mupdf gets the glyphs all wrong. | 17:25.06 |
| ray_laptop | but I did have a set of format-patch for the six commits (just in case) | 17:25.09 |
| Robin_Watts | ray_laptop: just do: "git branch marker" before you start. | 17:25.37 |
| | That way you'll have a new branch "marker" set to where you started. | 17:25.56 |
| | That way if you ever get into a bad state, you can always get back. | 17:26.13 |
| | Then when you're finally happy: git branch -D marker | 17:26.27 |
| pgogna | Point P of coordinates ( 425.250000; 434.325012 ) Rectangle described by A(297.001984; 337.410095) and B(529.804993; 515.269104)! mScale : 2.3711033 factor : 2.3711033 mXScroll : -684 mYScroll : 0 | 17:26.34 |
| | This is my debug values for touch point, rect, mscale,factor,mXScroll and mYScroll | 17:27.18 |
| chrisl | Robin_Watts: I don't think there is a way to get gs to dump the gids. If you want I can take a look at what's going on tomorrow morning? | 17:27.35 |
| pgogna | I am using a device with height width of 800x480 | 17:27.41 |
| Robin_Watts | chrisl: Thanks. | 17:27.45 |
| chrisl | Robin_Watts: if you drop me a mail with a bug number (I assume there's a bug?) | 17:28.18 |
| Robin_Watts | chrisl: There is, and I have a cutdown file. | 17:28.38 |
| | I will send a mail in a mo. thanks. | 17:28.43 |
| chrisl | Cool - I have to head out now, and I'll forget otherwise! | 17:29.02 |
| Robin_Watts | pgogna: So the thing you clicked on initially filled about 1/3 the width of the screen and extended off the top a bit? | 17:29.26 |
| | or off the bottom maybe. | 17:29.39 |
| | pgogna: I'm looking for confirmation that I'm reading the coords right. The thing you clicked on went from screen coords: 297 -> 529 | 17:30.32 |
| | 529-297 = 232. 800/232 != 2.37 | 17:31.24 |
| pgogna | Yes but I can see the complete box on the screen though. I think this is according the document spacem is it?\ | 17:31.30 |
| Robin_Watts | I can't make sense of those coords. | 17:32.32 |
| | Where did you click on the screen? In the middle at the top (or the bottom?) | 17:32.51 |
| pgogna | somewhere middle right | 17:33.41 |
| | it is a two column pdf. I double tapped on right side middle on a para | 17:34.03 |
| ray_laptop | Robin_Watts: btw, you can probably get what you want from psi/zfapi.c (I'd look at ps_get_glyphname_or_cid) or in gxfapi.c in gx_fapi_do_char where it calls that | 17:34.36 |
| pgogna | The para I tapped on is visible. I am completly zoom out. Full page is visible on the screen. | 17:34.39 |
| Robin_Watts | pgogna: So I don't even understand the touch coords. | 17:35.12 |
| ray_laptop | Robin_Watts: but maybe chrisl will take it for you. He certainly has 'been there, done that' | 17:35.13 |
| Robin_Watts | Point P of coordinates ( 425.250000; 434.325012 ) <- On an 800x480 device, that's in the middle at the top (or the bottom) | 17:35.39 |
| | You are using this in landscape mode, right? | 17:36.45 |
| | i.e. wider than it is tall ? | 17:36.54 |
| pgogna | Robin, I am writing better logs. give me 2 minutes. thanks | 17:37.52 |
| | I am trying to give you data one more time | 17:41.45 |
| | Touch X: 350.625 Touch Y: 428.90625 Document spaced X: 841.5 Document spaced Y: 851.775 Point P of coordinates ( 420.750000; 425.887512 ) Rectangle described by A(297.001984; 337.410095) and B(529.804993; 515.269104)! mScale : 2.3711033 factor : 2.3711033 mXScroll : -684 mYScroll : 0 | 17:41.50 |
| Robin_Watts | OK, and you're using the device in landscape format? | 17:42.22 |
| pgogna | Basically I have process the touches 3 times before I mapped them to find if they are in a block or not. I can explain you the 3 step process for the coordinates processing if you like. | 17:42.46 |
| | No Portrait | 17:42.55 |
| Robin_Watts | So it's 480x800, not 800x480. | 17:43.12 |
| pgogna | YEs, sorry I wrote wrong before. | 17:43.40 |
| Robin_Watts | so it's a portrait PDF page with 2 columns of text in it. | 17:44.15 |
| pgogna | Yes | 17:44.29 |
| Robin_Watts | There are gaps above and below the page where you can see the background ? | 17:44.47 |
| pgogna | Yes there is gap on top and bottom. | 17:45.32 |
| Robin_Watts | And you click on the right, in the middle. at 350x428. OK, that makes sense so far. | 17:46.20 |
| pgogna | Yes. | 17:46.43 |
| Robin_Watts | What do you mean by "Document spaced X: 841.5 Document spaced Y: 851.775" ? | 17:46.52 |
| pgogna | float scale = pageView.mSourceScale*(float)pageView.getWidth()/(float)pageView.mSize.x; float docRelX = (arg0.getX() - pageView.getLeft())/scale; float docRelY = (arg0.getY() - pageView.getTop())/scale; | 17:47.54 |
| Robin_Watts | pgogna: arg0.getX() is the screen X position of the touch ? | 17:49.45 |
| pgogna | yes | 17:50.01 |
| Robin_Watts | ok, that seems plausible | 17:51.13 |
| | That seems to suggest that if you drew a line from the top left of your document down and to the right, that you clicked somewhere on that line. Does that sound reasonable ? | 17:52.39 |
| | pgogna: hello? | 17:56.59 |
| pgogna | Yes | 17:57.24 |
| Robin_Watts | So presumably you're then scaling again somehow to get P ? | 17:57.53 |
| pgogna | Are you saying that we are doing and process and then reversing it? | 17:58.54 |
| Robin_Watts | no, I am saying I don't follow what you are doing with the coords. | 17:59.41 |
| | Look at the A->B rectangle. | 17:59.52 |
| pgogna | ok | 18:00.06 |
| Robin_Watts | If you're entirely zoomed out from the page, then the screen rectangle for the right hand column, should lie somewhere between 240 and 480. | 18:00.34 |
| | A.x = 297 = plausible. | 18:00.45 |
| | B.x = 529. 529 > 480 therefore off the right of the screen. | 18:01.13 |
| | So those aren't screen coords. | 18:01.23 |
| pgogna | Yes. I am trying to see what did I do to them :( | 18:03.52 |
| Robin_Watts | I have to head out for 10 mins. | 18:04.05 |
| pgogna | ok. thank Robin for the heads up | 18:05.09 |
| Robin_Watts | back, | 18:13.11 |
| ray_laptop | Robin_Watts: apparently my ~ray/repos/ghostpdl.git never got properly set up | 18:15.58 |
| Robin_Watts | ray_laptop: howso? | 18:16.16 |
| | I can see it from git.ghostscript.com | 18:17.10 |
| | but nothing has been pushed to it for 9 months. | 18:17.17 |
| | So... "git remote -v" and paste the results here. | 18:17.44 |
| ray_laptop | no results | 18:18.08 |
| Robin_Watts | ray_laptop: Eh? | 18:19.45 |
| | ray_laptop: From the msys prompt on your windows machine, within ghostpdl.git, do "git remote -v" | 18:21.00 |
| | Seriously that gives no results? | 18:21.04 |
| | You should see something like: | 18:21.25 |
| ray_laptop | oh, you mean from my working matchine. That has: | 18:21.25 |
| | personal ray@ghostscript.com:/home/ray/repos/ghostpdl.git (fetch) | 18:21.27 |
| | personal ray@ghostscript.com:/home/ray/repos/ghostpdl.git (push) | 18:21.28 |
| Robin_Watts | Right. | 18:21.49 |
| | But that's all? | 18:21.58 |
| ray_laptop | Robin_Watts: no, it has origin as well | 18:22.12 |
| | and cluster | 18:22.24 |
| Robin_Watts | OK. | 18:22.35 |
| | So what are you trying to do and not succeeding ? | 18:22.53 |
| ray_laptop | I'm trying to expose my changes for review (not sure by who, but for sure you and chrisl) | 18:24.58 |
| Robin_Watts | ray_laptop: And where are your changes? | 18:25.58 |
| | on your local master branch ? | 18:26.06 |
| ray_laptop | so I should: git push personal ? | 18:26.09 |
| | yes, local master now | 18:26.20 |
| Robin_Watts | That would push the current branch up, yes. | 18:26.27 |
| ray_laptop | and I am on branch master. Seems to be working. not suprisingly, taking a while | 18:26.57 |
| Robin_Watts | personally I always specify the branchname, in case I've changed to something else (git push personal master) | 18:27.16 |
| ray_laptop | Writing objects: 4% (5463/136555), 1.89 MiB | 80 KiB/s | 18:27.18 |
| Robin_Watts | ray_laptop: It's sending the last 9 months of changes too :) | 18:27.33 |
| ray_laptop | yep. | 18:27.39 |
| | all the devices/ reorg | 18:27.55 |
| pgogna | I am running simple for loop to get the blocks once I call fz_run_display_list. like this fz_run_display_list(pc->page_list, dev, &fz_identity, &afz_infinite_rect, &cookie); | 18:31.49 |
| | Is it that I am not sending the correct fz_identity that is why I am getting wrong bbox rect? | 18:32.24 |
| | Robin_Watts? | 18:32.42 |
| Robin_Watts | pgogna: If you are sending fz_identity in, then you will be getting rectangles out in the internal PDF document space. | 18:33.27 |
| | not screen coords. | 18:33.33 |
| | You have 3 different 'spaces' to think about. | 18:33.49 |
| | There is the 'document space'. | 18:34.05 |
| | There is the 'view space'. | 18:34.12 |
| | and there is 'screen space'. | 18:34.18 |
| pgogna | I am clear on this | 18:34.36 |
| | fz_matrix fz_identity = { 1, 0, 0, 1, 0, 0 }; | 18:34.39 |
| | I am setting fz_identity to this before I call run dis[lau | 18:34.54 |
| Robin_Watts | ok. so the coords you will get back from the text extraction will be between (0,0) and (page_width,page_height) | 18:36.47 |
| pgogna | ok | 18:37.13 |
| Robin_Watts | The page is then setup to scale that so that it just fills the screen. In your case, page_width will be scaled to be 480. | 18:38.07 |
| | page_height will be scaled to be page_height*480/page_width | 18:39.46 |
| | and screen space will be (initially) the same as view space, but with a vertical offset (to give the gap at the bottom of the screen). | 18:40.59 |
| | When we start to pan and zoom around the page, the values get more complicated, but the same basic setup is there. | 18:42.11 |
| pgogna | I understand Robin. | 18:49.24 |
| ray_laptop | Robin_Watts: OK, email sent to tech, but mostly to Marcosw, you and Chrisl about the bg_print change review. Not super urgent since I can send it to the customer as-is, but I wanted review before committing to origin. | 18:50.22 |
| | Robin_Watts: you can look over the threading issues to see if you spot anything. Probably chrisl can look at the devices/ updates to enable bg printing on some (many) | 18:51.21 |
| | Thanks in advance. | 18:51.43 |
| Robin_Watts | pgogna: So, if it was me, I'd want to add logging throughout the code. I'd want to be sure that every coordinate I got (be it from a click, or from a rectangle) was in the right document space. | 18:52.19 |
| ray_laptop | henrys: if you want to split up looking over the devices that now use gdev_prn_output_page, that might help | 18:52.27 |
| Robin_Watts | s/in the right document space/in the right space/ | 18:52.34 |
| | ray_laptop: I will look tomorrow. | 18:52.47 |
| ray_laptop | Robin_Watts: OK. Ta | 18:53.07 |
| Robin_Watts | Ah, do CIDFonts have different mappings to normal fonts? | 18:53.52 |
| ray_laptop | oops. my git push personal gave a bunch of remote: error: messages :-( | 18:53.57 |
| Robin_Watts | ray_laptop: Such as? | 18:54.09 |
| ray_laptop | remote: error: refusing to update checked out branch: refs/heads/master | 18:54.30 |
| | remote: error: By default, updating the current branch in a non-bare repository | 18:54.31 |
| | remote: error: is denied, because it will make the index and work tree inconsistent | 18:54.33 |
| | remote: error: with what you pushed, and will require 'git reset --hard' to match | 18:54.34 |
| | remote: error: the work tree to HEAD. | 18:54.36 |
| Robin_Watts | ray_laptop: Ah. you have a non bare repo. | 18:54.50 |
| ray_laptop | whatever that is :-/ | 18:55.00 |
| Robin_Watts | Do you ever do development work on casper? | 18:55.00 |
| | It means it's a repo with a checked out version. | 18:55.11 |
| ray_laptop | not often, but sometimes. | 18:55.17 |
| | so where do I go to do the git reset --hard (or what should I do) ? | 18:55.46 |
| Robin_Watts | Right. It is worried that you'll be happily working away on casper on head, and then someone else will come along and push a load of changes into your repo, changing the repo under you. | 18:56.04 |
| | Now, in this instance you're the only person using that repo, so it's probably not a problem. | 18:56.19 |
| | so we can tell the repo that you don't care. | 18:56.37 |
| | let me just google for how to do that :) | 18:56.52 |
| ray_laptop | so should I set receive.denyCurrentBranch to ignore (as it suggested) | 18:57.00 |
| Robin_Watts | Ah, exactly. | 18:57.16 |
| ray_laptop | remote: error: You can set 'receive.denyCurrentBranch' configuration variable to | 18:57.19 |
| | remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into | 18:57.20 |
| | remote: error: its current branch; however, this is not recommended unless you | 18:57.22 |
| | remote: error: arranged to update its work tree to match what you pushed in some | 18:57.23 |
| | remote: error: other way. | 18:57.25 |
| Robin_Watts | so on casper, change into ~ray/repos/ghostscript.git | 18:57.39 |
| ray_laptop | Robin_Watts: so where do I go to update the config ? | 18:57.45 |
| Robin_Watts | and do: git config receive.denyCurrentBranch ignore | 18:58.03 |
| | Then redo the push from your local machine again. | 18:58.38 |
| ray_laptop | I have ghostpdl.git but it says: error: could not lock config file .git/config: No such file or directory | 18:58.52 |
| Robin_Watts | let me look | 18:59.10 |
| ray_laptop | oops. I didn't cd to ghostpdl.git | 18:59.22 |
| | OK. that worked. | 18:59.37 |
| Robin_Watts | That looks like a bare repo to me :( | 18:59.38 |
| ray_laptop | so how come it looks OK on the website ? | 19:00.04 |
| Robin_Watts | Most of the repos on the website are bare ones. | 19:00.26 |
| | I'm confused. | 19:00.32 |
| | ray_laptop: There is nothing of any value in your remote repo, right? | 19:00.56 |
| | Let me clear it out and set it up again. | 19:01.22 |
| ray_laptop | Robin_Watts: OK. Thanks. | 19:01.57 |
| | I don't have anything I care about | 19:02.07 |
| | well it's gone now | 19:03.24 |
| | and now it's back Magic | 19:03.48 |
| Robin_Watts | Try pushing now. | 19:03.59 |
| ray_laptop | that was fast | 19:04.46 |
| | did it do anything ? | 19:04.51 |
| Robin_Watts | it did. | 19:04.56 |
| | http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=shortlog | 19:05.01 |
| | You can see your commits at the top now. | 19:05.07 |
| ray_laptop | or more importantly, you (and chrisl) can see them :-) | 19:05.33 |
| Robin_Watts | indeed :) | 19:05.43 |
| ray_laptop | marcosw: I wanted to make sure you saw the part of my email about adding BGPrint=true to the NumRenderingThreads weekly | 19:07.01 |
| marcosw_ | ray_laptop: I did not, but I'll do that. | 19:07.24 |
| ray_laptop | marcosw: if you think it should be a separate run, or maybe added to the 'all devices' run that's fine too | 19:07.38 |
| | marcosw: thankss | 19:08.00 |
| | time for a lunch break. At least my push didn't have to send all those objects again :-) | 19:08.41 |
| | bbiaw | 19:08.45 |
| pgogna | So, I am able to get my bbox rect (document space). Robin_watts: How do I transform a rect to screen space? | 19:11.33 |
| Robin_Watts | First, you convert it to viewspace. | 19:13.52 |
| | You know the width/height of the page in document units | 19:14.14 |
| | and you know the width/height of the page in the view units, so it's a simple scale. | 19:14.36 |
| | Then you convert from view to screen; which just involves adding the view position in. | 19:22.04 |
| pgogna | Is this already done anywhere in the code? | 19:23.42 |
| Robin_Watts | pgogna: I'm sure it's done everywhere in the core. | 19:25.33 |
| | in the code. | 19:25.36 |
| | In drawPage, we set up ctm before we call fz_run_display_list | 19:28.58 |
| | (That's in mupdf.c) | 19:29.06 |
| | That will result in the bboxes coming back in viewspace *I think*. | 19:29.21 |
| | That's probably the easiest way for you to work. | 19:29.48 |
| | Get the bboxes in viewspace. Then it should be easy to convert to and from screen space. | 19:30.15 |
| | chrisl: (For the logs) no need to hunt for that problem, I sorted it, thanks! | 19:57.06 |
| | tor8: Review on robin/master for you. It's a hack so that when we have a CIDFont, we don't fallback to fonts, only to CIDFonts. | 19:57.06 |
| | i.e. only to DroidSansFallback. | 19:57.06 |
| tkamppeter | henrys, I have seen these bugs, but I had more important things to do, especially fixes of user-reported bugs for Ubuntu 13.04, and prep for GSoC and OpenPrinting Summit. | 21:22.05 |
| henrys | tkamppeter: okay | 21:23.03 |
| | Forward 1 day (to 2013/05/01)>>> | |
IRC Logs