| | <<<Back 1 day (to 2014/05/19) | 2014/05/20 |
| kens | Going to exercise your superpowers chrisl ? | 08:55.19 |
| chrisl | I was going to kick xymox it's getting pretty annoying..... | 08:55.38 |
| kens | Agreed | 08:55.44 |
| chrisl | Oh, the power...... | 08:56.55 |
| kens | :) | 08:57.12 |
| chrisl | Well, that didn't work, and I don't really want to ban xymox...... | 09:08.47 |
| kens | Hmm | 09:08.57 |
| Robin_Watts | If you're going to start kicking/banning people for falling on/off the channel, then marcos is in trouble. | 09:15.11 |
| kens | me too :) | 09:15.25 |
| purb | pdf_array_get(annots, i); return the ith annot object............ but how to update this object? | 09:16.10 |
| | and how to save the updated object with the existing annot list | 09:16.54 |
| Robin_Watts | Well, if we look at where pdf_array_get is defined (object.h) the very next line declares pdf_array_put. | 09:19.01 |
| | That seems a reasonable thing to try :) | 09:19.14 |
| | Or are you talking about doing: o = pdf_array_get(annots, i) and then wanting to tweak o? | 09:20.05 |
| purb | I can't change the Ap values of any annotation.... how can I do this? | 10:34.22 |
| tor8 | sebras: curl is not portable. we shouldn't encourage its use as a regular third party dependency for mupdf | 11:12.29 |
| sebras | tor8: the reason I'm asking is that it is kind of neat to be able to build _only_ the mupdf source and see that there are no errors. | 12:12.51 |
| | tor8: so sometimes I do make third and then make just ot check this. | 12:13.09 |
| purb | how can I create a line annotation and how to add this annotation with the existing annotation list?????? | 12:14.57 |
| | I can't figure out to solve this problem......... | 12:15.38 |
| Robin_Watts | purb: Let's look in mupdf.c, where I pointed you before. | 12:18.41 |
| | in MuPDFCore_addInkAnnotationInternal | 12:19.16 |
| | You'll see that we allocate pts to be a list of fz_points, and fill them in. | 12:19.44 |
| | Then we call annot = pdf_create_annot(idoc, pc->page, FZ_ANNOT_INK) | 12:20.16 |
| | Then pdf_set_ink_annot_list(idoc, annot, pts, counts, n, color, INK_THICKNESS) | 12:20.50 |
| purb | How many fz_points are requeired? | 12:21.02 |
| | only 4? | 12:21.09 |
| Robin_Watts | How many do you need? | 12:21.26 |
| | ink annotations can be complex. | 12:21.33 |
| | In your case, for a simple line, possibly only 2 are required. | 12:21.43 |
| tor8 | sebras: right. I guess it shouldn't be too difficult to make that work. | 12:26.29 |
| | sebras: | 12:27.43 |
| | -third: $(THIRD_LIBS) | 12:27.46 |
| | +third: $(THIRD_LIBS) $(CURL_LIB) | 12:27.46 |
| | sebras: like on tor/master | 12:31.18 |
| purb | what is the use of jfieldID? | 12:37.18 |
| | I have write | 12:40.19 |
| | void pdf_addInkAnnotationInternal(pdfapp_t *app)//JNIEnv * env, jobject thiz, jobjectArray arcs) { fz_context *ctx = app->ctx; fz_document *doc = app->doc; pdf_document *idoc = pdf_specifics(doc); | 12:40.22 |
| | after that? | 12:40.34 |
| | after that? | 12:53.47 |
| | how can do for any sample annotation? | 12:54.30 |
| | I change the JNIEnv variable by pdfapp_t variable | 12:55.29 |
| | but how to manupulate others? | 12:55.53 |
| | but how to replace other variables? | 13:01.27 |
| | Can't see the structure of JNI structure elements............... | 13:02.11 |
| | hiiii | 13:05.28 |
| | anybody there? | 13:05.34 |
| | but how to replace other variables? | 13:10.03 |
| | hi xymox??????????? | 13:12.02 |
| | are you there? | 13:12.11 |
| | but how to replace other variables???? | 13:12.41 |
| | xymox: can you see the problem? | 13:13.16 |
| Robin_Watts | purb: I had stepped away for lunch. | 13:16.31 |
| | The JNIEnv stuff is all specific to the JNI interface. | 13:16.45 |
| | That's the interface between java and native methods. | 13:17.01 |
| purb | yes,, I know | 13:17.08 |
| | I change the JNIEnv variable by pdfapp_t variable | 13:17.14 |
| Robin_Watts | You don't have to deal with any of that, as you are coding on Windows. | 13:17.14 |
| | purb: Don't try and cut/paste the code. | 13:17.30 |
| | Write yourself new code based upon what you learn from reading this. | 13:17.42 |
| purb | I chage the code from android version to pdfapp version | 13:18.03 |
| | but jfieldID is an opaque type of variable | 13:19.15 |
| | how can I find the structure of jfieldID type | 13:19.45 |
| Robin_Watts | You can't. That's part of the JNI interface. | 13:21.18 |
| | We use the jfieldID values just to read stored values out of java objects. | 13:22.10 |
| | For instance, this field is called witha list of java 'Points', and we need to read the actual 'x' and 'y' values out of those java objects. | 13:22.41 |
| | You don't have to cope with any of that, so this should be utterly irrelevant to you. | 13:23.07 |
| Fabio_ | Hi everyone | 13:27.56 |
| Robin_Watts | Fabio, hi. | 13:28.04 |
| Fabio_ | Hi have a question about the signal handling of the native muPDF code on the android platform | 13:29.15 |
| Robin_Watts | I don't think there is any :) | 13:29.52 |
| Fabio_ | As the native library it is used by the upper Java application by means of JNI | 13:30.05 |
| | is there a way to catch the native signals in the Java app? | 13:30.41 |
| Robin_Watts | I am confused by what you mean by signals? | 13:31.37 |
| | You mean like signals as in SEGV etc? | 13:31.48 |
| Fabio_ | I would explain my problem ... sometimes the library is not able to render the PDF pages therefore the core process died with some signal (SIGSEV, SIGBUS, etc). In such a case I would like recreate a new core instance without crashing all the app | 13:32.41 |
| Robin_Watts | Fabio_: Right. | 13:33.18 |
| | It would be nicest for us to fix the core so it didn't SEGV :) | 13:33.37 |
| | but if you wanted to add signal handling to catch such things, I suspect you'd need to add a signal handler at the mupdf.c level. | 13:34.17 |
| | And then you could propogate that back to the java layer using a new 'checkCoreIntact' method or something. | 13:34.54 |
| Fabio_ | yes ... exactly however solves all bugs requires time ... as workaround we could catch the signals and propagate them as Java exceptions | 13:35.00 |
| | ok ... do you mean that it is not already implemented so far? Should I have itself to change the mupdf.c code ? | 13:35.55 |
| Robin_Watts | It is not implemented so far, no. | 13:36.35 |
| | You would need to change mupdf.c | 13:36.41 |
| | There may possibly be android mechanisms for catching such signals as exceptions, but I am not aware of them. | 13:37.15 |
| | scary. taxman. | 13:37.44 |
| kens | Yeah I thought that | 13:37.50 |
| chrisl | Robin_Watts: Just thought exactly the same - after our discussion yesterday! | 13:38.09 |
| Fabio_ | I looked for an answer on Google too but I got the same answer ... the native code should catch the signal and propagate it to Java ... however I hoped that there was something already implemented without changing the native code | 13:39.20 |
| kens | is warming up Marcos' garage again, I wonder how hot it is in SFO today...... | 13:40.30 |
| henrys | kens:I'm curious how my machines will warm things up this summer in the new place. | 13:43.50 |
| kens | Hmm, could be a warm summer :-) | 13:44.13 |
| | Ah, has Marcos come to complain ? Or just early for the meeting..... | 13:46.21 |
| Fabio_ | Anyway thanks for your answer ... My problem is that I know Java but not so much about JNI and C ... anyway I'll try to found and maybe implement a solution :-) | 13:47.30 |
| Robin_Watts | Fabio_: Good luck! | 13:47.44 |
| | Let us know how you get on, or if you have any more questions. | 13:47.57 |
| marcosw | kens: what am I supposed to complain about? | 13:50.13 |
| kens | Me heating up your garage.... | 13:50.23 |
| henrys | kens:actually we should move the entire operation to one of your houses in the UK as your demand for heat is higher than Marcos' | 13:50.36 |
| kens | True. Chris has hte best broadband I htink | 13:50.57 |
| Robin_Watts | electricity prices are probably higher here... | 13:51.19 |
| | Morning mvrhel_laptop. All packed? | 13:53.20 |
| marcosw | kens: it's cooled down considerably, the high is forecast at 68 day (which is 4.85 stone). | 13:53.25 |
| Robin_Watts | 11.3333333 fathoms. | 13:54.14 |
| kens | Hmm, what's that in linguine ? Or Olympic swimming ppols ? | 13:54.16 |
| mvrhel_laptop | Robin_Watts: no. spent a lot of yesterday getting other stuff wrapped up around here | 13:54.21 |
| Robin_Watts | 0.04 wales' | 13:54.27 |
| marcosw | I did looked at moving to a colo when it was 100 last week but the lowest quote I could find was $600. The problem is that the machines need 40 Amps total power at their peak. | 13:54.40 |
| kens | Hmm that's qwuite a bit | 13:55.02 |
| marcosw | the highest allowed ambient operating temperature for the servers is 95 and even when it's 100 outside I don't think it gets about 90 in my garage, so we should be okay. though the fans are running really fast even at idle :-) | 13:55.42 |
| henrys | marcosw: maybe test file reduction should be added to the agenda again | 13:57.06 |
| rayjj | morning, all | 14:09.31 |
| Robin_Watts | morning, ray | 14:12.08 |
| henrys | meeting in 15 minutes | 14:16.29 |
| rayjj | have my (large) coffee and am ready to go | 14:29.20 |
| sebras | tor8: ok. what you pasted looks good, but of course I haven't tested. | 14:29.33 |
| henrys | I didn't really have much for the mupdf/gs meeting, other than looking at customer bugs and updating the agenda. | 14:29.46 |
| | marcosw: are you going to be able to take on SOT testing at your "facility"? | 14:30.45 |
| marcosw_ | henrys: I don't know what's involved. I havne' been in the SOT testing loop. | 14:31.05 |
| Robin_Watts | The plan is to move ATS over to an uberserver in marcosw's garage once we have it in shape. | 14:31.18 |
| henrys | marcosw: I have to think you are reaching near limit of what is reasonable at a residence. | 14:31.28 |
| Robin_Watts | At the moment it's at Josephs place because it's more convenient for him to work on it locally | 14:31.57 |
| | (although he's in DC until the end of this week) | 14:32.09 |
| henrys | Robin_Watts: it might be interesting for marcosw_ to know the joules involved before volunteering. | 14:32.50 |
| marcosw_ | henrys: my goal is to be listed on top500.org, so I have a way to go. | 14:33.07 |
| paulgardiner_lap | Had one bad review of the iOS app saying "Does not support JavaScript". Not sure what they mean by that. | 14:33.29 |
| Robin_Watts | henrys: Well, this would be reusing existing hardware. | 14:33.30 |
| henrys | rayjj: did you want to beat on COLOR INDEX more? | 14:33.46 |
| Robin_Watts | but it would be additional load of course. | 14:33.48 |
| henrys | looking at Robin_Watts 695153, can't we simply have a limit on when to punt with interpolation? | 14:38.09 |
| Robin_Watts | henrys: We could, but then you run the risk of having a sharp discontinuity in the middle of the image. | 14:38.47 |
| | interpolation becomes more important as we scale up mode. | 14:39.05 |
| henrys | mvrhel_laptop: good luck on the trip! Do you need anything? | 14:39.07 |
| mvrhel_laptop | henrys: no I think I am all set. | 14:39.44 |
| | This is the 4th trip. I think we have everything dialed in pretty well | 14:41.50 |
| Robin_Watts | mvrhel_laptop: Are you revisiting places, or going to new places? | 14:42.30 |
| mvrhel_laptop | I am going to try to get out a newer gsview release today for people to try if all goes well | 14:42.47 |
| | Robin_Watts: A bit of each | 14:43.00 |
| | Korea is all new obviously | 14:43.05 |
| Robin_Watts | oh, of course. | 14:43.29 |
| henrys | Robin_Watts: so we'll just leave the bug open? I don't see how else it could be fixed without a limit. | 14:44.14 |
| rayjj | mvrhel_laptop: I hope Takena-san is able to help you navigate Korea as well as he does .jp | 14:44.18 |
| henrys | mvrhel_laptop: is Takani going to korea also? | 14:44.42 |
| mvrhel_laptop | rayjj: We have some other people helping us there I believe. Also, I am not sure he is going to be there in korea. It is just Scott Miles and I | 14:44.54 |
| rayjj | mvrhel_laptop: Oh, OK. Well, have a good trip. At least Miles limited how many places you go each day in japan, iirc | 14:45.44 |
| mvrhel_laptop | so tomorrow will be a long day. fly to SFO. Fly to korea, meeting about 3 hours after arrival | 14:46.06 |
| henrys | mvrhel_laptop: oh korea first? | 14:46.37 |
| mvrhel_laptop | yes. We will be there until Sunday | 14:46.52 |
| rayjj | henrys: Bug 695153 is somewhat related to my enhancement bug 693684 | 14:47.00 |
| mvrhel_laptop | Scott did arrange a trip to the DMZ on Saturday | 14:47.09 |
| henrys | mvrhel_laptop: naturally, practice ducking | 14:47.34 |
| Robin_Watts | mvrhel_laptop: I hope you remember the correct procedure for what to do if you tread on a landmine. | 14:47.36 |
| rayjj | mvrhel_laptop: did you pack a helmet ? | 14:47.42 |
| mvrhel_laptop | all good suggestions | 14:47.54 |
| rayjj | Robin_Watts: what are your concerns about limiting interpolation causing a discontinuity ? | 14:48.31 |
| tor8 | mvrhel_laptop: I hope you like chili and fermented cabbage :) | 14:49.07 |
| Robin_Watts | rayjj: Imagine I have a 2x2 image, with black pixels in the top left and bottom right corners, and white pixels elsewhere. | 14:49.10 |
| henrys | paulgardiner: is this review at the apple store? | 14:49.12 |
| mvrhel_laptop | tor8: Yes I am wondering about the food. I have not really had much Korean food | 14:49.30 |
| Robin_Watts | Now scale that up to fill the background of a page. | 14:49.30 |
| paulgardiner | Yes. | 14:49.32 |
| pedro_pc | mvrhel_laptop - depends what you like, but its pretty good | 14:49.48 |
| Robin_Watts | rayjj: With interpolation, that's a nice graduated effect. Without it's a hard discontinuity. | 14:50.03 |
| tor8 | mvrhel_laptop: sam-gyeop-sal is one of my favorites. very unhealthy :) | 14:50.04 |
| paulgardiner | I'd have been interested to know what he expected to be able to do | 14:50.12 |
| Robin_Watts | I have never eaten Korean food, but a friend had to go there on business, and she had real problems. | 14:50.37 |
| mvrhel_laptop | tor8: I will keep an eye out for that | 14:50.42 |
| pedro_pc | mvrhel: bi bim bap too, and the obligatory korean barbeque :) | 14:50.47 |
| rayjj | Robin_Watts: OK, so limiting interpolation as with my (someday) enhancement will let the interpolation load be reduced, but not eliminated | 14:51.10 |
| tor8 | if you can't cope with chili, or are vegetarian, korea is not a place to eat | 14:51.16 |
| henrys | mvrhel_laptop: how long are you in korea? | 14:52.18 |
| mvrhel_laptop | We arrive Thursday and we fly to Japan on Sunday | 14:52.31 |
| rayjj | mvrhel_laptop: so meetings Thur and Fri ? | 14:52.55 |
| henrys | mvrhel_laptop: I was big on hotel food in taiwan. | 14:53.00 |
| tor8 | mvrhel_laptop: make sure to try some of the soups (dwen-jang-chige). cold noodle soup (mul naeng-myeon) is also quite nice and not so spicy. | 14:53.04 |
| mvrhel_laptop | Yes meetings Thursday and Friday. Saturday is free and Sunday travel. | 14:53.22 |
| | tor8: ok thanks. I will jot these down | 14:53.33 |
| rayjj | mvrhel_laptop: don't let Miles cajole you into eating what he's having. He eats all kinds of strange stuff | 14:53.41 |
| tor8 | mvrhel_laptop: if the food is too strange for you, grilled fish is a pretty nice safety net. that, and pizza :) oh, and if you go to mcdonalds or burger king, bring your own salt. | 14:54.47 |
| henrys | anything else for the meeting, tor8? mupdf, mujs business? | 14:56.15 |
| tor8 | henrys: not much news. I've been beating down the mupdf bug list to something manageable, about to start triaging the enhancement list. | 14:56.41 |
| | nothing has happened on the mujs front, bugs have been keeping me too busy to write docs like I ought to | 14:56.56 |
| | henrys: there's less than a dozen unassigned mupdf bugs left. most of the others are all in paul's area of expertise (mobile apps and forms work) | 14:57.47 |
| | but I guess paul won't be able to get to those for quite some time... | 14:58.01 |
| henrys | tor8: probably not - one idea I had was Robin_Watts and paulgardiner could rotate in and out of SOT - so if Robin_Watts wanted to hack on Good while paulgardiner switched to those issues that would be fine. Let's see what they thing about that. | 15:00.32 |
| | s/thing/think | 15:01.18 |
| Robin_Watts | anything that limits my exposure to SOT is a good thing :) | 15:01.30 |
| | but I'd be starting from scratch with the Good stuff, as I haven't been following it. | 15:01.47 |
| | pedro_pc and paulgardiner have been bearing the brunt of that. | 15:02.08 |
| henrys | that sort of blends us into the next meeting. | 15:02.10 |
| pedro_pc | nicely done ;) | 15:02.24 |
| Robin_Watts | Jogu can't be with us for today. | 15:02.26 |
| paulgardiner | Good SDK changes are possibly complete, until tests show otherwise that is. | 15:02.28 |
| Robin_Watts | But he says: "still just plugging away at ATS to try and get other bits working (eg. mac client, seeing if we can drop wheezy, getting valgrind going)" | 15:03.15 |
| henrys | okay but I we still waiting for access to the test servers pedro_pc ? | 15:03.22 |
| | s/I/art | 15:03.23 |
| | s/I/are | 15:03.23 |
| pedro_pc | Good are going to set us up with an account for their mobile messaging so we'll be able to test the interop between the GoodforEnterprise mail/chat app and SO | 15:03.58 |
| paulgardiner | Found a few more pngs mentioning Picsel that need altering but besides that the Good work on iOS will likely be stalled until we have the server access we've been promised | 15:04.10 |
| Robin_Watts | We think we are almost at the point of wanting to do new app store releases. | 15:04.51 |
| | There are 2 big things standing in the way. | 15:05.09 |
| pedro_pc | I'm pretty much at the same point (a couple of bits to sort out here) but can shift onto more bugfixing until Good sort out the login | 15:05.25 |
| Robin_Watts | Firstly, the font metric changes haven't gone into master yet. | 15:05.40 |
| | There is no problem with putting them in, except for the fact they change the layout of pretty much every test file. | 15:05.59 |
| henrys | paulgardiner, pedro_pc - I am getting frustrated with them, they are constantly pinging for status and we seem to be waiting for them to do something. | 15:06.02 |
| paulgardiner | Or I could do some PDF bugs!!!!! | 15:06.04 |
| Robin_Watts | Now, for gs, we'd commit it and be done with it, but the problem is that the ATS tests test interactive behaviour. | 15:06.29 |
| henrys | paulgardiner, pedro_pc and it seems what we are waiting for is trivial. | 15:06.40 |
| pedro_pc | henrys> I prodded Brad yesterday but I mentioned to paul I'm going to ping agan today if I haven't had any response | 15:06.49 |
| Robin_Watts | 'click on this bit of text', 'scroll this much', 'click this button' etc. | 15:06.50 |
| | so we probably actually need to spend some time looking at the scripts working out which ones need updating. | 15:07.12 |
| henrys | Robin_Watts: I'll catch up I wanted to finish Good. | 15:07.14 |
| Robin_Watts | henrys: Sure, sorry. | 15:07.26 |
| paulgardiner | Another pressing issue is the thing that Robin is describing. Maybe the only blocker on app store releases (non-GOOD that is) | 15:07.41 |
| Robin_Watts | There are something like 12000 image differences with the font changes. | 15:08.27 |
| paulgardiner | That and getting the apps reasonably hand tested | 15:08.28 |
| Robin_Watts | Item 2 on the blocker-for-release is testing. | 15:08.46 |
| | ATS is great, but probably we need some hand testing. | 15:09.07 |
| | And this probably should involve us pulling in other people to test. | 15:09.23 |
| rayjj | paulgardiner: let me know if you need me to photoshop out anymore Picsel | 15:09.34 |
| Robin_Watts | cos fresh eyes are always better. | 15:09.37 |
| henrys | paulgardiner, pedro_pc okay so miles and I will also work on pushing good from the other end. They have reported a disgruntled customer with a list of vague problems - and I'm pushing back that we need to get things running before fixing a hypothetical list of issues. | 15:09.55 |
| paulgardiner | Thanks rayjj. Will keep that in mind. So far it's looking like images for which we have no photoshop files, though. :-( | 15:10.31 |
| pedro_pc | henrys: do we have any bug reports from them we need to chase? | 15:11.04 |
| rayjj | paulgardiner: I'm reasonably good at using phototshop on just images | 15:11.09 |
| henrys | Robin_Watts: are the font metrics buying us a lot? | 15:12.02 |
| paulgardiner | rayjj: Oh okay. That might be handy | 15:12.27 |
| Robin_Watts | They are not critical. | 15:12.33 |
| | We'll still go wrong with them in, but they need to go in at some point unless we completely abandon the idea of trying to match layout. | 15:12.57 |
| | So we could push them past the release, but it's just delaying the work to some later date. | 15:13.25 |
| henrys | Robin_Watts: trying to figure out how we squeeze in all the resultant testing though? | 15:14.04 |
| paulgardiner | And the font metrics is one of the few improvements we have to show. The vast majority of work has been just getting control of what we've inherited. | 15:14.06 |
| | I don't think the font metric changes add to our need for hands on testing | 15:15.21 |
| rayjj | having to reverse engineer Microsoft's text layout that's beyond what's given in the font metrics sounds like a nightmare | 15:15.32 |
| Robin_Watts | rayjj: Indeed. | 15:15.48 |
| rayjj | it's what we sort of thought was already in the product :-( | 15:16.17 |
| | oh, well | 15:16.32 |
| Robin_Watts | I have a really simple file with just a couple of lines of text in a known font that breaks at a different place than expected. | 15:16.37 |
| henrys | paulgardiner: I guess I'm confused I thought the font metric changes motivated a lot of manual testing? | 15:16.41 |
| rayjj | Robin_Watts: breaks as in the line break happens at a different place ? | 15:17.11 |
| Robin_Watts | When I reach a sane stage I'd like to dig through the font engine to compare its measurement of the text with (say) freetypes. | 15:17.28 |
| henrys | also to be consider do we want to make more progress on the layout so we only have to check it once? | 15:17.31 |
| Robin_Watts | rayjj: Yes. | 15:17.31 |
| | henrys: There are 2 types of manual testing required here. | 15:17.53 |
| paulgardiner | I was halfway through typing that same sentence | 15:18.17 |
| Robin_Watts | 1) Is the app built from the master branch with all the latest fixes in still stable/working properly (as opposed to the old version built from the 2-1-28-release-branch) | 15:18.46 |
| paulgardiner | One is actual manual testing the other is more the manual alteration of the automated tests | 15:18.51 |
| Robin_Watts | 2) Manually updating the automatic testing scripts to cope with the fact that the stuff that needs clicking on has moved around the page. | 15:19.33 |
| | As an example of 2)... | 15:19.41 |
| pedro_pc | there's a lot of compexity in the Word layout which makes it very difficult to match exactly (and different versions of Word running on different platforms dnt match exactly) | 15:20.04 |
| Robin_Watts | suppose i have a test that loads a document. This document contains text, plus an image flowed with the text. | 15:20.07 |
| | The test might click on the image and rotate it. | 15:20.14 |
| pedro_pc | I think we can get a lot closer if we want true fidelity as there are quite a few unsupported features | 15:20.39 |
| Robin_Watts | now, if the font causes the text to layout differently, the image might be in a different place, so the test will click on something else. | 15:20.45 |
| | pedro: Yes, we are never going to match exactly in all cases. | 15:21.07 |
| henrys | pedro_pc: yes but we agreed to match Libre Office and Word if they match. Doesn't that make this doable? | 15:21.07 |
| Robin_Watts | henrys: We agreed that we'd *try* to match Libre Office and Word if they matched :) | 15:21.42 |
| pedro_pc | its technically feasible, but I guess what I'm trying to say is that its not necessarily all quick fixes | 15:22.26 |
| Robin_Watts | The picsel font engine works in fixed point rather than floats, and there is lots of rescaling of widths going on. | 15:23.32 |
| henrys | pedro_pc: I have no doubt it is hard but it bring it into the realm of doable, we aren't expecting word only or word legacy compatibility | 15:23.39 |
| pedro_pc | SO was compact embedded product, whereas openoffice/libreoffice were desktop oriented form the ground up | 15:23.55 |
| Robin_Watts | I'm hoping that that accounts for some of disparity between the line breaks, and further hoping that it might be possible to improve it to give a better match. | 15:24.26 |
| | but even so, I'm not expecting to be able to match 100% in all circumstances. | 15:24.46 |
| henrys | Robin_Watts, paulgardiner : my issue with the testing is simple if you change the layout all the files change and we have to look at them, so do we do *all* the layout changes on a branch over a long period and look at the them once or do we incrementally update and look at a lot more test files? | 15:25.07 |
| paulgardiner_lap | henrys: but there are extra problems with the interactive tests | 15:25.42 |
| Robin_Watts | henrys: It is possible that if I found a problem in the font engine and fixed it, we'd have to revisit some files again, yes. | 15:26.50 |
| paulgardiner_lap | "interactive tests" was a bad phrase | 15:27.17 |
| Robin_Watts | But I hope that the font metrics changes make an order of magnitude more changes than other things would. | 15:27.21 |
| paulgardiner_lap | I meant automated texts that perform interaction | 15:27.31 |
| pedro_pc | agrees - if we don't have the metrics right then we can't expect antyhing else to layout with fidelity to Word/PPT | 15:28.01 |
| paulgardiner_lap | With those, as Robin described, we may need to update the test to ensure it still tests what it is supposed to | 15:28.04 |
| | s/texts/tests/ in last but one message | 15:28.35 |
| henrys | Robin_Watts: how have you verified the metrics? Comparison with the word fonts on android, do we know if iOS is different? | 15:29.04 |
| Robin_Watts | henrys: word fonts? | 15:29.32 |
| | The Picsel fonts are very good visual clones of the standard windows fonts. | 15:29.59 |
| | but the metrics were wrong. | 15:30.06 |
| henrys | Robin_Watts: MS Word fonts used on android or iOS. I would imagine it likely they were tweaked for the mobile platforms, no? | 15:30.44 |
| Robin_Watts | so I ripped the metrics out of the windows fonts, and updated our fonts to have the same metrics. | 15:30.50 |
| | MSWord fonts aren't on android or ios. | 15:30.59 |
| | Your iphone will not have Arial or Tahoma :) | 15:31.33 |
| | (possibly unless you've installed Microsoft Office) | 15:31.54 |
| rayjj | Robin_Watts: I thought MS had office for Android. | 15:32.05 |
| henrys | Robin_Watts: oh when you install the new Office on iOS you don't get the fonts. | 15:32.10 |
| | Robin_Watts: let me look I'm sure you must. | 15:32.34 |
| tor8 | henrys: not surprising, you can't add to the base system so any fonts you add will be local to your app | 15:32.40 |
| rayjj | so, presumably those fonts exist then. Are they the same ? And does MS's android office "get it right", i.e. match the desktop office ? | 15:32.50 |
| Robin_Watts | henrys: You might get fonts installed as part of office. | 15:33.19 |
| | but they are not there as standard, so we can't rely on them. | 15:33.33 |
| chrisl | Why would you "tweak" fonts for a mobile platform?? Surely the point of scaleable fonts is not having to do that kind of crap....... | 15:33.37 |
| Robin_Watts | chrisl: seconded. | 15:33.45 |
| | You have to figure that if MS are offering identical rendering on all platforms they must install fonts as part of their office offering, otherwise they fall at the first hurdle. | 15:34.56 |
| | The fonts aren't there as standard, so we provide our own. | 15:35.10 |
| | It seems reasonable that the clones we provide really ought to have the same metrics as the things we are trying to clone. | 15:35.26 |
| henrys | Robin_Watts: fair enough | 15:36.46 |
| Robin_Watts | But you are right, we could delay putting the font changes in, and keep them on a branch. | 15:37.12 |
| | and we could keep rebasing that up and maybe do a few ATS files at a time. | 15:37.35 |
| paulgardiner_lap | I'd say it was definitely not worth delaying a Good release for the font changes, seeing as we are without an app there at the moment, but then again we're not ready to go with Good | 15:38.29 |
| Robin_Watts | And we could try to do further font engine/layout fixes on that branch, so we only take the pain of sorting the ATS stuff once. | 15:38.46 |
| | But the longer we delay, the longer until we get any of the benefits this (hopefully) gives. | 15:39.15 |
| paulgardiner_lap | For the non-Good versions of the apps, I'm less certain what we gain by releasing before we have the font changes in. | 15:41.24 |
| henrys | okay so let's bite the bullet and look at a lot of tests. marcosw_ and I can help. | 15:41.47 |
| paulgardiner_lap | I guess the sooner we have a version we've released out there the better, in that we'll know that all reported bugs are with reference to something we're able to build. | 15:42.23 |
| Robin_Watts | henrys: It's not just looking at the tests. | 15:43.37 |
| | It's figuring out which ones need to be updated, and doing that updating. | 15:43.52 |
| henrys | Robin_Watts: so you don't simply look at the file I'd "press a button" to update? | 15:47.03 |
| Robin_Watts | henrys: Nope. | 15:47.14 |
| | I run the tests, and we'll get a (set of) webpage(s) of differences. | 15:47.47 |
| | we then need to look at each file (control, new, diff, similar to bmpcmp) to see if they look noticably different. | 15:48.31 |
| | If they do, then you need to look through the script that this tests images are for (again, this can be done on the web interface). | 15:49.04 |
| | You need to decide if the script is actually still testing the functionality it was meant to (maybe it's selecting a different word to turn it pink, say), in which case it's fine. | 15:49.43 |
| | but if you see that the script is now failing to test what it was supposed to, then someone needs to fix that script. | 15:50.07 |
| | That involves editing the text of the script in an editor and us rolling that updated script into the commit. | 15:50.29 |
| henrys | and why would a script need to change if we are only changing the metrics? | 15:51.10 |
| paulgardiner_lap | The scripts have cooridinates in them | 15:51.36 |
| Robin_Watts | henrys: Suppose I have a test script that does: | 15:51.41 |
| pedro_pc | because the layout may have changed a button position for example, and the script was emulating a click on a screen position | 15:51.47 |
| Robin_Watts | LOAD_DOCUMENT blah.pdf | 15:51.48 |
| | CLICK 100,100 | 15:51.52 |
| | DRAG 50,50 | 15:51.57 |
| henrys | I see | 15:52.00 |
| Robin_Watts | etc. | 15:52.03 |
| henrys | get rid of those tests and do what gs does ;-) | 15:52.28 |
| henrys | gets more coffee | 15:52.38 |
| pedro_pc | :) | 15:52.45 |
| | makes testing of editing functionality a bit tricky ;) | 15:52.57 |
| Robin_Watts | henrys: Testing GS is not the same as testing SOT. Testing SOT is equivalent to testing GhostView, including page flipping, searching, page extraction etc. | 15:53.34 |
| | It's the "canned interaction" nature of the tests that makes it hard. | 15:53.51 |
| rayjj | Robin_Watts: If we get to a point where we match Office layout on static tests, that's a better first step IMHO. And a LOT simpler since there is no messing with "fixing scripts" | 15:54.58 |
| Robin_Watts | rayjj: So you propose that until we get to match office layout on static tests we abandon all the existing tests on SOT? | 15:55.40 |
| rayjj | no, just ignore the "interactive" tests until we have the layout working for the static files | 15:56.33 |
| henrys | Robin_Watts, pedro_pc we do have to get the testing in line with our resources and this does sound too "heavy" for us to handle. | 15:56.44 |
| rayjj | it's not my call, but just my opinion | 15:56.54 |
| Robin_Watts | rayjj: We can't realistically do that and continue to ship a product with any degree of confidence. | 15:57.37 |
| | The interactivity *is* the product. | 15:57.49 |
| | Having something that doesn't render quite right is annoying. Having a product that just fails to work is unacceptable. | 15:58.26 |
| pedro_pc | I thinkn all these views are valid, but imho we're trading some customers priorities for others; if I'm buying SO on the appstore I'd be less worried if some of the content didn't display exactly like the dektop than if someone had completely broken my ability to edit text in a word doc | 15:58.29 |
| | if I was a printer mfr I may have a different view | 15:58.40 |
| rayjj | presumably 'fixes' in the layout won't break editing, but it will break scripts that have canned coordinates since what they are diddling with might have moved | 15:58.41 |
| paulgardiner_lap | rayjj: these tests that involve interaction check that we haven't completely broken a feature, like copy and paste, rotating an image. There not so much about matching office | 15:58.42 |
| pedro_pc | all valid - just need to decide who we're prioritising | 15:58.57 |
| paulgardiner_lap | s/There/They're/ | 15:59.09 |
| Robin_Watts | rayjj: You might reasonably hope so, but the cross dependencies in this stuff are incredible. | 15:59.40 |
| rayjj | projector companies and printer companies will be much more concerned about getting the image right. | 15:59.42 |
| paulgardiner_lap | rayjj: the fong changes wont break the features these tests check, but they may break the tests themselves | 15:59.58 |
| rayjj | Robin_Watts: yeah, I smelled that | 16:00.00 |
| Robin_Watts | rayjj: Until we ship them a version that crashes whenever they flip page too fast. | 16:00.17 |
| | or go backwards a page etc. | 16:00.23 |
| pedro_pc | rayjj: the scripts may need updateing, but if we take the approach of dumping the difficult ones and focussing on layout fidelity then we need to be pretty careful what we release on the appstores in the meantime | 16:00.29 |
| Robin_Watts | We could dump all the widget tests (that would make joseph happy, I think). | 16:01.06 |
| paulgardiner_lap | ... so once the font metrics break some of our editing-features tests, we are flying without a parachute on later changes to those features | 16:01.26 |
| rayjj | paulgardiner: yes, my point. every time we 'fix' the layout, then the scripts might break since stuff moved. So fix the layout first (and hopefully not have to change it too often). Then worry about fixing the scripts | 16:01.32 |
| pedro_pc | agreed - we're not shipping them (but they implictly test stuff that may not be done elsewhere) | 16:01.36 |
| Robin_Watts | yes, once we dump a test, bringing it back is hard. | 16:02.38 |
| paulgardiner_lap | rayjj; I get you now, but sadly I think fixing the layout will be a very long winded thing that goes on over a period of years and we wont be able to hold off on all other types of change until it's done | 16:03.00 |
| Robin_Watts | Yes. | 16:03.59 |
| | The font changes are (I hope) special because they result in pretty much every file changing. | 16:04.20 |
| paulgardiner_lap | ... but that does bring up the point that this is probably not a one-off problem. We are often going to need to update the interaction tests when we alter layout | 16:04.29 |
| Robin_Watts | layout changes should hopefully be much smaller after that. | 16:04.42 |
| henrys | so let's say you change the metrics - what is the man hour estimate to fix the scripts, just so I can get my head around this? | 16:04.43 |
| paulgardiner_lap | Robin_Watts: yeah that's a point | 16:04.43 |
| Robin_Watts | but if there are changes to font measurement in the font engine, that could do a similar thing. So maybe it makes sense to try to do those together. | 16:05.18 |
| | henrys: That's a good question. | 16:05.28 |
| | I looked at the diffs once, then ran screaming away. | 16:05.41 |
| | We probably need to look back at them and see how far down the rabbit hole goes. | 16:06.16 |
| | Is it the top 20 scripts that need fixing or the top 200? | 16:06.30 |
| henrys | I thought perhaps in the history of picsel a change of this magnitude was done and you had a sense of how long it took but I guess that wasn't your department ;-) | 16:06.59 |
| rayjj | how many scripts are there ? | 16:07.13 |
| Robin_Watts | No, I have never been involved in such a widespread change. | 16:07.31 |
| rayjj | guesses from Robin's comment there are over 200 | 16:07.37 |
| Robin_Watts | find . -name *.ath | wc -l running now. | 16:08.09 |
| pedro_pc | henrys: yeah, there was a test team (from 10-30 people across the sites) and a tools team handling ATS/review/bugzilla etc (5-10 depending on time of year) | 16:08.22 |
| rayjj | Robin_Watts: find . -name "*.ath" | wc -l I hope | 16:08.44 |
| pedro_pc | we can possibly grep the scripts for interaction commands and do a more top-down approach | 16:08.50 |
| Robin_Watts | 3877 | 16:08.53 |
| rayjj | gawd! | 16:09.13 |
| Robin_Watts | rayjj: indeed. | 16:09.30 |
| henrys | pedro_pc: right so the QA is completely disproportionate to artifex engineering resources and it has to be changed. | 16:11.17 |
| rayjj | and the effort seems disproportionate to the revenue | 16:12.00 |
| pedro_pc | nods - that was based on continuous test across a whole range of products and platforms - I think we're targetting a lot less now | 16:12.12 |
| rayjj | if I recall what we were originally looking for it was a package that would let us import office docs into our products and push that to our licensed customer base | 16:14.19 |
| Robin_Watts | Right. We are targetting a smaller range of platforms (I hope). | 16:14.20 |
| | and the point of having these scripts is that they actually reduce testing in the long run. | 16:14.35 |
| rayjj | we've sort of drifted off that goal | 16:14.35 |
| pedro_pc | rayjj: quite possible - there was significant licencing revenue from the embedded & phone markets and high expectations on QA. We need to figure what makes sense now | 16:14.37 |
| Robin_Watts | rayjj: That train sailed ages ago :( | 16:14.50 |
| rayjj | that train sailed out of the barn ;-) | 16:15.31 |
| Robin_Watts | ooh, I like that. | 16:15.49 |
| rayjj | or, that train sailed off the dime and out of the barn | 16:16.18 |
| Robin_Watts | I think it's fair to say that we wouldn't consider working on gs without the cluster now. | 16:17.09 |
| rayjj | Robin_Watts: right. but that's where the amount of effort in maintaining the cluster scripts is "reasonable" | 16:17.54 |
| Robin_Watts | Similarly, I don't believe we'd want to consider shipping SOT without ATS (or something similar) doing regression testing for us. | 16:17.54 |
| rayjj | even mujstest is not subject to breaking the js when appearance changes for an unrelated reason | 16:18.42 |
| Robin_Watts | rayjj: And the effort of maintaining the ATS scripts is generally reasonable. It's just this is a special case. | 16:18.55 |
| pedro_pc | one thing we could look at is keeping core & feature tests in ATS and having soem interactive smoke tests for interaction, but that's a trade-off between deveoping tests and bums on seats | 16:19.10 |
| Robin_Watts | rayjj: That's because mujstest is rendering PDF, which has no reflow involved. | 16:19.20 |
| rayjj | Robin_Watts: I hope so. But I guess we will find out the hard way, by having to do it (at least) once | 16:19.34 |
| Robin_Watts | One possibility is to cheat at this. | 16:20.45 |
| pedro_pc | seems to be losing more charcaters on the wifi kb again | 16:20.55 |
| rayjj | of course management (henry and miles) will be asking all during the process "how much longer will this take" :-) | 16:21.02 |
| | Robin_Watts: ooh. Cheating. I like that | 16:21.18 |
| | just on principle | 16:21.24 |
| Robin_Watts | We don't push the font changes to master. | 16:21.29 |
| | When we want to do a release we sort out a place in git to release from. | 16:21.51 |
| | Do all the ATS tests on that. | 16:21.56 |
| | Then cherry-pick the font stuff onto that, tag and build. | 16:22.09 |
| paulgardiner_lap | I see where you are going | 16:22.10 |
| Robin_Watts | Our human testing should spot any problems. | 16:22.20 |
| rayjj | Robin_Watts: so we leave the font metrics as now for the ATS ? and work on layout changes *with* the font metrics fixed ? | 16:22.45 |
| Robin_Watts | That would enable us to postpone the pain of the font stuff until we do any font changes later. | 16:22.53 |
| | rayjj: Yes, we can juggle the font stuff in and out on our dev branches. | 16:23.14 |
| rayjj | Robin_Watts: that makes sense (I think) | 16:23.34 |
| Robin_Watts | Ideally, when we think it's all settled down, we should take the font pill at some point, but hopefully it'll be a combined font+font engine pill then. | 16:24.21 |
| | and maybe we can cull some ATS tests in the meantime. | 16:24.43 |
| rayjj | Robin_Watts: and hacks to the layout engine, possibly | 16:24.46 |
| Robin_Watts | rayjj: I suspect that hacks to the layout engine are going to produce a much smaller changeset. | 16:25.06 |
| rayjj | Robin_Watts: and for the layout improvements, we focus on comparison of static tests | 16:25.27 |
| | Robin_Watts: right | 16:25.34 |
| marcosw | Robin_Watts: are the ATS test results available to look at? | 16:26.09 |
| Robin_Watts | The layout improvements, if the change sets are reasonable, can go in in advance of the font stuff too. | 16:26.23 |
| | marcosw: Yes, ish. | 16:26.32 |
| rayjj | because getting the image "right" is what projector and printer companies will want. And people doing editing will only care if they happen to export their edited document to real office and see it different | 16:27.06 |
| Robin_Watts | http://twiki.ghostscript.com/do/view/GhostDocs/AutomatedTest | 16:27.06 |
| | marcosw: You need to follow the SSH tunnel section there. | 16:27.30 |
| | and that probably requires you having sent Joseph (or pedro?) a public_key | 16:27.53 |
| rayjj | marcosw: once you do that, you are inside the event horizon :-) | 16:28.37 |
| marcosw | Robin_Watts: seems simple enought. | 16:28.55 |
| Robin_Watts | pedro: Are you in a position to update the required public keys? | 16:30.54 |
| pedro_pc | Robin: i don't have sudo access on toast so can't add marcosw; I'll prod joseph | 16:30.55 |
| Robin_Watts | OK. Probably everyone should mail joseph a public key. You're all going to want to have a nosey at it at some point :) | 16:31.21 |
| marcosw | I've sent my public key to everyone I could think of. | 16:31.36 |
| | (i.e. jogux and pedro_pc). | 16:31.46 |
| henrys | Robin_Watts: is there some reason not to all share an account for tech staff say? | 16:31.53 |
| pedro_pc | its possibly worth having an 'artifex' user on toast so that we can ssh | 16:31.54 |
| rayjj | we probably want a few people with sudo access (at least henrys and marcos) | 16:32.02 |
| Robin_Watts | henrys: It makes sense to have separate users on intranet.picsel.com, because that way you can see your jobs on ATS vs anyone elses. | 16:32.47 |
| | but for the ssh tunnel, one user would be OK, except that would mean sharing a private_key around a group of people. | 16:33.15 |
| | if we can't do that securely, possibly Joseph/Pete would object as that would be an entry point into their system. | 16:33.39 |
| | rayjj: At the moment, the ATS stuff is set up inside emobix's network. | 16:34.05 |
| | hence root on the gateway machine is restricted to joseph (which seems reasonable) | 16:34.35 |
| | when it goes onto the uber server in Marcosw's garage, then it can be opened up. | 16:34.49 |
| | It's currently at emobix towers cos it's easier to do some of the VM hacking that joseph has been doing locally. | 16:35.31 |
| rayjj | Robin_Watts: I just noticed an anomaly on bug 695153 | 16:36.56 |
| henrys | Robin_Watts: okay can somebody send me one of these scripts so I can understand this a bit better, preferably and interesting one? | 16:37.12 |
| | s/and/an | 16:37.22 |
| marcosw | Robin_Watts: I think we should start looking at the differences and just flag those that are different just because of font differences (i.e. the script still tests what it's supposed to). I don't see any way around looking at the thousands of differences. | 16:39.31 |
| Robin_Watts | henrys: Do you have an SOT checkout? | 16:39.42 |
| henrys | Robin_Watts: yes | 16:39.51 |
| pedro_pc | can add marcos's public key to my account for now | 16:40.00 |
| Robin_Watts | henrys: epage/ats/ath/.../*.ath | 16:40.02 |
| pedro_pc | marcos: want to see if you can ssh in as pete? | 16:40.23 |
| henrys | oh sorry though all of that stuff was on the server | 16:40.31 |
| | s/though/thougth | 16:40.38 |
| Robin_Watts | henrys: No, the scripts are part of the code tree. Hence you commit updated scripts to cope with updated code behaviour. | 16:40.57 |
| rayjj | Robin_Watts: that makes sense | 16:41.18 |
| marcosw | Robin_Watts: the scripts seem simple to edit; the ones I've just looked it are even commented. | 16:41.31 |
| pedro_pc | henrys: it keeps the scripts in sync with the code based on cvs/git tags | 16:41.35 |
| Robin_Watts | marcosw: Yeah, this is quite a sensible system. | 16:41.52 |
| marcosw | we should use it on GhostView :-) | 16:42.35 |
| Robin_Watts | marcosw: If we are going to test ghostview interactively, then yes, we'd need something like this. | 16:43.03 |
| kens | OK off now, goodnight all | 16:44.48 |
| rayjj | I'd recommend scripts that are 'logical' as in 'Right-Click File-Menu' instead of click (20, 30) | 16:45.02 |
| henrys | so a screenshot based system would use too much space? I can see having a corresponding image for each edit, then the script would not need manual updates. | 16:46.12 |
| Robin_Watts | rayjj: If you're testing stuff with a single UI, yes. | 16:46.50 |
| | ATS is not testing stuff with a single UI :) | 16:47.02 |
| | henrys: I don't follow, sorry. | 16:47.16 |
| pedro_pc | rayjj> there have been instances of that, but you need a full command set per app and the UI was what changed most often between customers | 16:47.16 |
| rayjj | Robin_Watts: I was talking about gsview | 16:47.22 |
| pedro_pc | ah :) | 16:47.37 |
| rayjj | where things are more controlled | 16:47.49 |
| Robin_Watts | rayjj: Sure. | 16:47.55 |
| | rayjj: The smart way to do that would be to be able to map screen locations to commands. | 16:48.22 |
| pedro_pc | for HTML testing (when we used to do html) we had a DOM mapping so that we could interact with named objects | 16:48.47 |
| Robin_Watts | So if we ever change the position of the file menu etc, it'd just be a single definition that changed. | 16:49.04 |
| | I think the ATS scripts try to do something a bit like that using includes, but I don't think it's pervasice. | 16:49.29 |
| | pervasive. | 16:49.32 |
| henrys | Robin_Watts: I mean capturing the screen image for each edit and testing that against version n - 1's screen image. | 16:52.31 |
| Robin_Watts | henrys: That's what happens. | 16:53.00 |
| | Whenever we run these tests they dump out screenshots. | 16:53.25 |
| | Those are compared to the previous versions screenshots. | 16:53.33 |
| | If they all match, good news! If not, you get to view the differences on the web. | 16:53.49 |
| henrys | Robin_Watts: oh I thought these script were formulating there own idea of what the screen should look like based on coordinates and such. So now I'm not really seeing the script updating should be common but I'm probably still missing something. | 16:56.50 |
| Robin_Watts | The idea is that you write a script once to test a given feature. | 16:57.17 |
| | Every commit it produces a screenshot, compares to the last one, and 99% of the time they match and there is no problem. | 16:57.38 |
| | and you can be confident that your feature is working. | 16:57.47 |
| henrys | the usual case should be just replace the old screenshot no change to script | 16:57.58 |
| Robin_Watts | Every now and then, something might change (say you update an icon or something). Then you look at the diff, you see it's correct, you just go ahead and accept the change. | 16:58.34 |
| | In *rare* cases, something shifts around on the screen, and the coords the script was clicking on are wrong. That requires a script update. | 16:59.12 |
| | The problem is that the font update potentially causes lots of these 'rare' cases all at once. | 16:59.32 |
| marcosw | Robin_Watts: I hope the definition of *rare* is better for SOT than it is for Ghostsript/GhostPCL. There seem to be changes very 6 months or so that require me looking at tens of thousands of bitmaps (though many of those were for color management changes, which presumably isn't an issue with SOT). | 17:01.29 |
| Robin_Watts | bulk bitmap changes are less rare than bulk script changes. | 17:02.13 |
| henrys | Robin_Watts: got it. | 17:02.24 |
| Robin_Watts | I had realised that the font changes were going to produce bulk bitmap changes. | 17:02.38 |
| | I was blissfully unaware of the bulk script changes until the middle of last week. | 17:02.59 |
| | My screams were heard in neighbouring towns. | 17:03.11 |
| henrys | Robin_Watts: but there are other ways of navigating without coords, - next word etc. presumably we could eliminate many of these coordinate dependent tests, no? | 17:03.45 |
| | bbiam | 17:04.30 |
| Robin_Watts | henrys: The point is that these scripts are intended to simulate driving the app as a user would do it. | 17:04.54 |
| | The user has a touchscreen, and maybe a keyboard. | 17:05.02 |
| | We could build more smarts into the app to recognise different commands, but then we'd be testing the test code, not testing the real code. | 17:05.42 |
| | but if you want to recode 3877 scripts, feel free :) | 17:05.54 |
| kim0 | Hi folks, I'm working on converting a bank from Windows to open-source desktop. I'm hitting a problem getting a dot-matrix printer to print correctly. I traced the driver to here .. Am I in the right place to ask questions .. Thanks | 17:12.42 |
| Robin_Watts | kim0: Potentially, yes. | 17:13.20 |
| | I'm assuming you're using ghostscript ? | 17:13.25 |
| kim0 | Robin_Watts: mm, I'm using the cups printing system .. I assume it uses GS under the hood ? | 17:14.00 |
| | The printer is: http://www.fujitsu.com/emea/products/printers/tmpl_printers_DL3750plus.html | 17:14.04 |
| Robin_Watts | kim0: For some things, yes. | 17:14.14 |
| kim0 | That's the printer, and the driver used was "epsonc" | 17:14.32 |
| | tell me I'm in the right place :) | 17:15.12 |
| Robin_Watts | The first thing we'd ask you to do here is to reproduce your problem using ghostscript. | 17:15.12 |
| | If you can do that, then maybe we can help. | 17:15.20 |
| kim0 | mm lovely .. Any docs how to do that | 17:15.32 |
| Robin_Watts | We won't go digging into cups problems. | 17:15.37 |
| | You possibly want to speak with the cups people. I think there is a #cups ? | 17:15.53 |
| | Failing that tkamppeter may be able to point you somewhere. | 17:16.02 |
| kim0 | printing from low level "lp" commands are also broken | 17:16.02 |
| | I'm sort of quite sure it's a low level driver issue .. but whatever you say | 17:16.30 |
| | It does print, but the characters are hazzy .. things that are middle-centered, become left centered ..etc | 17:17.09 |
| Robin_Watts | kim0: yeah, but the problem might be with cups, or with your distros gs installation etc. | 17:17.18 |
| kim0 | Robin_Watts: Very well .. so what I should do, is print from app to PS file .. Then start GS on that PS file, and have it talk to the printer ? | 17:18.06 |
| | any hints/docs how to do that please ? | 17:18.14 |
| | Robin_Watts: Another thing .. The printer seems to speak those 3 protocols (DPL24C+ : ESC/P2 : XL24E) .. Is any of them recommended ? | 17:19.19 |
| Robin_Watts | kim0: The cups people can probably tell you how to get the exact commands that cups is calling out of it. | 17:19.32 |
| | kim0: http://hplipopensource.com/node/225 | 17:20.18 |
| | That will tell you if gs is involved, and if it is, what the command used was. | 17:20.45 |
| kim0 | Robin_Watts: Thanks, very helpful! | 17:21.49 |
| | Let me know if you have any thoughts on if I should follow the path of changing the printer protocol | 17:22.11 |
| Robin_Watts | kim0: To be honest I haven't got a clue. You'll probably want to experiment and pick whichever one works best for you. | 17:29.31 |
| kim0 | Thanks | 17:30.19 |
| marcosw | Robin_Watts: I have access to the SOT results. Now what to I do? Clicking on results takes me to a page of results but I can't find the bitmaps. | 18:09.49 |
| Robin_Watts | Ok. so at the top of the page, you have the ATS bar, right? | 18:10.25 |
| rayjj | Robin_Watts: I know you're having too much fun with SOT, so I'll have a look at the '153 issue. I was going to look at making sure we 'skip' above/below left/right outside the clip path, but we'll still need to process 'support' source lines/pixles outside the clippath for the filter to work "reasonably". Do you want me to take that bug, or do you want it for when your sanity fades ? | 18:10.30 |
| marcosw | yeah | 18:10.31 |
| Robin_Watts | And in Results you have "scheduled jobs" | 18:10.39 |
| | (click on that) | 18:10.43 |
| marcosw | okay | 18:10.50 |
| rayjj | Robin_Watts: first I'm trying to look at why -r17 is so much worse than -r18 | 18:11.05 |
| marcosw | all red except for 28 and 29 | 18:11.06 |
| Robin_Watts | Then if the User name field is set to marcos you won't see anything. | 18:11.13 |
| | ah, ok. | 18:11.15 |
| marcosw | I'm logged in as atsadmin. | 18:11.28 |
| Robin_Watts | Ok, clear the username and then you'll see the same as me. | 18:11.43 |
| | Do you have a '95' ? | 18:12.13 |
| marcosw | yes. | 18:12.19 |
| Robin_Watts | TaskRun ID 95 that is. | 18:12.21 |
| | actually... use 91. | 18:12.41 |
| marcosw | okay. | 18:12.50 |
| Robin_Watts | anything which says "ATH" in the right hand side is a test that uses the scripts I was talking about. | 18:13.07 |
| | So, in the "ResultID" column for that job, you should have 401 ? | 18:13.31 |
| | click on that. | 18:13.34 |
| marcosw | for 91 the results id is 398 | 18:13.51 |
| Robin_Watts | Not if you go up 3 to the most recent run of 91. | 18:14.15 |
| | but that was a bad example. | 18:14.34 |
| | Let me find a better one. | 18:14.39 |
| | Put 'robin' in the username field | 18:15.00 |
| | and look at the top one. Should be result 362 | 18:15.13 |
| marcosw | yes, 362 | 18:15.37 |
| Robin_Watts | That's still a bad example. hold on... | 18:15.56 |
| marcosw | oops, nearly ra-ran a test. better stop clicking on stuff at random :-) | 18:16.31 |
| Robin_Watts | Ok, let's try 342 | 18:16.33 |
| marcosw | Says Not valid for Image updates:... | 18:16.54 |
| Robin_Watts | indeed. | 18:17.00 |
| | don't worry about that for now. | 18:17.07 |
| | So we have an expandable list of the different scripts. | 18:17.19 |
| | 186 diffs in all. | 18:17.28 |
| | 185 of which are in ue2fileviewer. | 18:17.39 |
| marcosw | hold on, I was clicking on random stuff again. let me find the ue2fileviewer | 18:18.09 |
| Robin_Watts | product -> lomond -> ue2fileviewer | 18:18.31 |
| | You can either drill down like that, or you can click at the top on "All failing images" | 18:18.53 |
| | If you click on "All failed images" you'll see we have 4 pages of diffs. | 18:19.18 |
| marcosw | all failing images is what I trying randomly clicking on (not really random, but you get the idea). | 18:19.29 |
| Robin_Watts | I was testing a change to the app that caused the pan behaviour to be different in some circumstances. | 18:19.51 |
| | I think the net effect was that some pans to display newly selected things weren't happening. | 18:20.25 |
| | hence stuff appearing in different places. | 18:20.33 |
| marcosw | yup. | 18:21.13 |
| Robin_Watts | but the scripts for these examples obviously load a document, select a cell or two, then bring up formatting options to change it. | 18:21.27 |
| | results 300 and 301 are the font changes I was talking about. | 18:22.05 |
| marcosw | what is lomond vs. non lomond? | 18:22.58 |
| | lomond runs much faster... | 18:23.16 |
| Robin_Watts | OK. In the olden days Picsel used to hardcode the apps. | 18:23.39 |
| | Then they had the idea that it'd be a really good idea to build an SDK whereby other people could build apps etc using our spiffy graphics libs. | 18:24.10 |
| | So they developed a system whereby you could build an app using a set of 'controls'. | 18:24.46 |
| | These controls would range from buttons, to bits of text, to ways of moving other controls around in 2d and 3d etc, and other controls that showed files. | 18:25.25 |
| | The idea was that you could build powerful, graphically rich apps without knowing about how it all worked underneath. | 18:26.02 |
| | That project was called lomond. | 18:26.18 |
| marcosw | and presumably were portable across platforms. | 18:26.25 |
| Robin_Watts | In practise, the only people that ever really used it were picsel themseles. | 18:26.28 |
| | yes. | 18:26.30 |
| | It was known as "Picsel UX" (or "Picsel'sUX" for obvious reasons) or UE2. | 18:27.08 |
| | You'll frequently hear us refer to UE2. Normally prefixed by an expletive, and followed by "how can you *have* this many macros?" etc | 18:27.43 |
| | The main Smart Office app is based on Lomond. | 18:28.25 |
| marcosw | I see. seems like a bit of a muddle. | 18:31.06 |
| Robin_Watts | Writing apps with lomond is not so bad. | 18:32.05 |
| | extending lomond itself is where it gets painful. | 18:32.15 |
| marcosw | do the same set of test files get run with both lomond and non lomond or are they distinct? | 18:32.33 |
| Robin_Watts | distinct. | 18:32.41 |
| | but certainly, when you have umpteen different customers all wanting to differentiate their offering by modifying the UI, it's a semi-sane strategy | 18:33.09 |
| | At one point Picsel tried encapsulating the app UI inside flash movies. | 18:33.42 |
| | So people would write the UI in flash and have the actionscript call down to drive the underlying libraries. | 18:34.22 |
| purb | what will be the value of n and count in the function """pdf_set_ink_annot_list(idoc, annot, pts, counts, n, color, INK_THICKNESS)"" --------- If I want to draw a line annotation | 18:35.09 |
| marcosw | I wouldn't want to debug such a thing, nor support it :-) | 18:35.10 |
| Robin_Watts | marcosw: indeed. | 18:35.28 |
| marcosw | I just realized you said "tried", so it didn't work? | 18:35.44 |
| Robin_Watts | turns out that flash is really bad on battery powered devices. | 18:35.47 |
| | it worked, but it never took off. | 18:35.58 |
| marcosw | I believe Apple told us that a long time ago... | 18:36.07 |
| Robin_Watts | Yeah, but that was for a whole other slew of reasons :) | 18:36.35 |
| marcosw | if one were so inclined and wanted to look at the 301/302 results and mark ones that were clearly different due to just font differences and therefore didn't require changes to the test scripts how would one do that? | 18:37.15 |
| Robin_Watts | "mark ones"? No idea. | 18:37.29 |
| marcosw | accept the difference? Whatever term is appropriate. | 18:38.05 |
| Robin_Watts | The way I'd do it would be to pick "All failed images" or "Weighted failed images" and to look at pages of results, making a list of those that need further attention. | 18:38.32 |
| | That way we can divvy up the pages of results etc. | 18:39.06 |
| marcosw | There isn't a button in the ATS user interface to mark results? I'm shocked! | 18:39.31 |
| Robin_Watts | Once we have a list of the files that fail, we can fix them locally, then roll them into a new commit and retest. | 18:39.33 |
| | marcosw: It used to be hooked up to the review system. | 18:39.57 |
| | You'd post your patch, test it, you'd mark it as "passes, with expected bitmap changes" and then when your reviewer marks it as being passed it's committed, and ATS updates automatically. | 18:40.41 |
| | We're not using the review system though, cos it was CVS based. | 18:40.55 |
| | So generally after we do a commit we rerun tasks 5 and 6 and they update the baseline bitmaps. | 18:41.22 |
| | Honestly, I understand a fraction of ATS. | 18:41.42 |
| | It would cope with running autobuilds and all sorts of tests, including on wierd and wacky hardware. | 18:42.12 |
| marcosw | Robin_Watts: that's 100% more than I do. | 18:42.20 |
| Robin_Watts | Picsel had a cabinet full of ipaqs running wince and linux etc. | 18:42.41 |
| | Ideally, we'd do all our release builds through ATS. | 18:43.14 |
| | It's just not feasible to have all the toolchains that Picsel used on every dev machine. | 18:43.57 |
| marcosw | I'll leave that for people above my pay-grade to sort out... | 18:44.14 |
| Robin_Watts | especially when some were expensively licensed compilers. | 18:44.19 |
| marcosw | which is probably anyone else :-) | 18:44.31 |
| | Looking at the 301 results it appears the differences are in line spacing, but for 90 rotated text this manifests itself as character spacing. These seems "wrong". | 18:45.02 |
| rayjj | Have the bug for 0920 fixed. Turns out BT / ET aren't the right place since the SMask is not yet processed. I had to bury it more places. Now to try a regression run... | 18:45.11 |
| Robin_Watts | marcosw: What page? | 18:45.38 |
| marcosw | test #47 on the All Failed Images page 1 | 18:46.06 |
| Robin_Watts | marcosw: No, I suspect that I've changed the metrics for the characters with a ' | 18:47.40 |
| | If you waggle the mouse pointer in/out of the left hand image it changes. | 18:48.02 |
| purb | hiiii Robin_watts: what will be the value of "n and count" in the function """pdf_set_ink_annot_list(idoc, annot, pts, counts, n, color, INK_THICKNESS)"" --------- If I want to draw a line annotation | 18:49.43 |
| marcosw | I see. How do we want to divide up looking at the differences? Who else besides me is stupid enough to volunteer for this. | 18:49.54 |
| Robin_Watts | marcosw: I suspect this would work best if we allocated everybody 15 pages or so. | 18:51.44 |
| | Then once we have a list of the scripts that need fixing, that can divvied out between fewer people. | 18:52.15 |
| | purb: So the header file says: | 18:52.45 |
| | pdf_set_ink_annot_list: set the details of an ink annotation. All the points of the multiple arcs | 18:53.19 |
| | are carried in a single array, with the counts for each arc held in a secondary array. | 18:53.20 |
| | void pdf_set_ink_annot_list(pdf_document *doc, pdf_annot *annot, fz_point *pts, int *counts, int ncount, float color[3], float thickness); | 18:53.22 |
| | So pts points to an array of points. | 18:53.43 |
| | counts points to an array of ints. | 18:53.58 |
| | ncount is the number of entries in the array of ints. | 18:54.11 |
| | Each count entry identifies how many control points there are for that segment. | 18:54.42 |
| | so counts[0] = 1 | 18:54.56 |
| | For a single line, you probably want: | 18:55.13 |
| | counts[0] = 1, counts[1] = 1; | 18:55.24 |
| | points[0] = start point, points[1] = end point. | 18:55.40 |
| | and ncount = 2. | 18:55.46 |
| | purb: OK ? | 18:55.48 |
| | marcosw: Possibly we could use a twiki page to make the list on? | 18:57.36 |
| rayjj | I guess I could have run the regression with some filters and just lowres :-/ | 19:01.53 |
| marcosw | Robin_Watts: back (was on the phone) | 19:08.04 |
| Robin_Watts | marcosw: I'm about done for the night. | 19:19.11 |
| | If you want to, start working forwards through 300 and 301 all failed images. Let me know how far you get. | 19:19.46 |
| | I'll do some tomorrow, and try and rope pete/paul in to help for a bit. | 19:20.08 |
| | and we'll see how long it's going to take. | 19:20.24 |
| | seem fair? | 19:20.30 |
| | If it's taking hours then we can reconsider the approach. | 19:20.43 |
| marcosw | Robin_Watts: If you are still around could you make a twiki page and I'll update it with how far I get today. I'm not sure where to put it on the twiki. | 19:39.34 |
| henrys | marcosw: it looks like open office and friend do regression testing like we do then don't even attempt to automate the interactive or editing stuff: https://www.openoffice.org/qa/testcase/assertions/edit/index.html. | 20:40.39 |
| | presumably interactive testing is done much less frequently. | 20:42.50 |
| marcosw | henrys: I suspect they have a lot more volunteers to help with testing than we do as well. | 21:15.15 |
| Robin_Watts | marcosw: back. | 22:29.19 |
| | marcosw: Just email me wherever you get to (or mention it here) | 22:30.30 |
| | stupid rebooty windows. | 23:15.21 |
| | Forward 1 day (to 2014/05/21)>>> | |
IRC Logs