| | <<<Back 1 day (to 2012/04/23) | 2012/04/24 |
| mvrhel | Robin_Watts: If you want to take a look at any of the segv's that is fine | 04:51.24 |
| | Also, I can't quite figure out where things are going wrong in the warnings on the clist stat initialization. the warnings | 04:52.34 |
| | ./base/gxclist.c:497: warning: missing braces around initializer | 04:52.36 |
| | ./base/gxclist.c:497: warning: (near initialization for 'cls_initial.tile_color_devn[0]') | 04:52.37 |
| | ./base/gxclrast.c:572: warning: missing braces around initializer | 04:52.39 |
| | ./base/gxclrast.c:572: warning: (near initialization for 'cls_initial.tile_color_devn[0]') | 04:52.41 |
| diverdude_ | Hello, how do i convert a plain simple textfile to pdf in commandline? | 07:08.02 |
| kens | Using what ? | 07:08.11 |
| diverdude_ | thats what im asking | 07:08.48 |
| | what can i use to do that? | 07:08.53 |
| kens | OpenOffice. | 07:09.01 |
| diverdude_ | thats not commandline | 07:09.10 |
| | i have only a terminal | 07:09.14 |
| kens | I believe it has a command line interface | 07:09.22 |
| diverdude_ | ok, but its not installed...isnt there a simpler way? | 07:09.43 |
| kens | Text files have no layout information, PDF files do, so you need to add layout information. | 07:09.58 |
| chrisl | diverdude_: use a2ps and then convert the PS to PDF using Ghostscript | 07:10.06 |
| kens | You oculd write a PostScript program to do it, and have GS interpret it | 07:10.10 |
| | Like I was saying :-) | 07:10.21 |
| diverdude_ | chrisl: ahhh yes now were talking :) much better | 07:10.52 |
| vtorri | ps2pdf exists too | 07:12.20 |
| chrisl | ps2pdf is ghostscript | 07:12.37 |
| vtorri | ha | 07:12.42 |
| | ok | 07:12.44 |
| chrisl | It's just a shell script that calls GS with the pdfwrite device | 07:13.05 |
| diverdude_ | when i try a2ps i get this error: /usr/bin/lp: Error - no default destination available. | 07:14.27 |
| vtorri | a2ps -o f.ps f.txt | 07:14.46 |
| sebras_ | paulgardiner: I manage to crash mupdf consistently on my HTC sensation. | 08:55.19 |
| | basically I rotate the phone to wide screen, bring up a simple text-only pdf with several pages, and click the page progressbars at opposite ends quickly and repeatedly (say 30-40 times). Eventually mupdf is force closed. | 08:57.17 |
| | I realize this is a horrendous test case, but still it seems to be reliably triggered. | 08:57.54 |
| Robin_Watts | sebras_: Can you reproduce the problem whilst banging your head on the wall? | 09:26.56 |
| sebras_ | Robin_Watts: give me a second and I'll try. | 09:27.37 |
| kens | "You're holding it wrong" | 09:27.55 |
| sebras_ | Robin_Watts: yes, I can reproduce it. but now I have a bruise on my forehead. ;) | 09:28.23 |
| Robin_Watts | :) | 09:28.59 |
| sebras_ | actually I'm thinking that this either is the result of a race condition or from a memory leak. | 09:29.09 |
| Robin_Watts | Those seem like reasonable guesses. | 09:29.54 |
| sebras_ | maybe it can be triggered in another use case which is more... let's say normal. | 09:30.05 |
| | I'm not saying that this is a 1.0 showstopper. far from it. but maybe it is worth to take a look later. | 09:31.18 |
| Robin_Watts | sebras_: Yeah, it's probably worth hunting for it. | 09:35.58 |
| sebras_ | Robin_Watts: if I manage to setup an android debug-environment at home I'll take a look later tonight. I noticed this while waiting for a compilation at work... | 09:38.18 |
| tor8 | Robin_Watts: paulgardiner: ping. | 10:40.54 |
| paulgardiner | tor8: hi | 10:41.03 |
| tor8 | I wrote some things an hour ago, they haven't shown up in the log so I guess they were eaten by the net split | 10:41.26 |
| | paulgardiner: anyway, I ran into some oddities when testing the android app for 1.0 | 10:41.41 |
| | things I thought were fixed. hitting "enter" in the search field doesn't launch a search, and highlights disappear when the device is rotated. | 10:42.07 |
| paulgardiner | I remember fixing the first, but I heard someone else mention it was broken again. | 10:42.55 |
| | Might it be working on some devices and not others? Perhaps there are several cases that need handling. | 10:43.48 |
| | I'll just have a look to see if the fix I put in before is still in my copy, at least | 10:44.46 |
| tor8 | it could be a tablet vs phone thing | 10:45.12 |
| | I tested it on the phone | 10:45.18 |
| paulgardiner | My phone is off for repair, but apparently will be back today or tomorrow | 10:46.13 |
| | Ha. Just while typing that, there was a knock at the door, and I now have my phone back. Handy timing. | 10:47.30 |
| | Hmmm. Code below "React to Done button on keyboard" is present in my copy here. I'll diff with master, but I guess there must be other cases. | 10:50.12 |
| | I guess it's not unlikly that Done is different from Rtn | 10:50.53 |
| | tor8: I've found some info that might be relevant. Looks like we may need setOnKeyListener in addition to setOnEditorActionListener. I'll just go and unpack my phone. | 10:58.41 |
| tor8 | paulgardiner: yeah, there's a Return-like arrow on the button on my phone | 10:59.31 |
| | but no Done button | 10:59.36 |
| Robin_Watts | paulgardiner: Did you get your phone back then? | 11:05.12 |
| | D'Oh. Should read logs :) | 11:05.23 |
| paulgardiner | 10 mins ago :-) | 11:05.29 |
| Robin_Watts | Did they fix the camera? | 11:05.41 |
| paulgardiner | Not sure yet. They didn't do any additional damage. So that's one relief. | 11:06.14 |
| | Looks like they've factory reset it, so I just have to mess about through the initial menus | 11:06.44 |
| Robin_Watts | runs helen to station. bbs. | 11:10.26 |
| sebras_ | tor8: are you able to reproduce my insanity test that I described before your desire? | 11:38.16 |
| tor8 | sebras_: after about a minute, yes... | 11:42.57 |
| Robin_Watts | ok, back. Is it worth me trying to reproduce/hunt down this mupdf thing? | 12:20.36 |
| | or do you guys have it in hand? | 12:21.07 |
| sebras | Robin_Watts: I'm at work so I'm not looking at it until this evening. | 12:21.24 |
| | don't know if tor8 is working on it. | 12:21.43 |
| tor8 | I'm busy with my tax declaration :( | 12:22.40 |
| sebras | tor8: right. | 12:23.05 |
| | tor8: btw, the downloads over at google code still carry the old thirdparty package. | 12:23.35 |
| tor8 | sebras: yes, I haven't uploaded the new ones yet. I want the android search thing fixed first. | 12:24.34 |
| sebras | tor8: right. | 12:24.44 |
| Robin_Watts | tor8: Can you put the new thirdparty up, but just not make thirdparty.zip point to it yet ? | 12:25.37 |
| | Or at least put it somewhere I can get it ? | 12:25.45 |
| | oh. it's just google code. Ignore me. | 12:25.56 |
| sebras | Robin_Watts: yes, but the default download directory points to googe code. | 12:26.42 |
| tor8 | Robin_Watts: it's on mupdf.com/download/ | 12:26.56 |
| Robin_Watts | tor8: yeah, got it. sorry. | 12:27.26 |
| | I can reproduce the android death here. | 12:53.03 |
| | I do not believe that mupdf is crashing inside a native call. | 13:27.13 |
| | Must get lunch. | 13:27.27 |
| sebras | Robin_Watts: ok, so that makes it likely that it simply runs out of memory and gets killed perhaps. | 13:27.41 |
| Bo98 | paulgardiner: http://pastebin.com/YzHUhzE7 <-- That's just quickly explaining how I put MuPDF into my existing Eclipse project. I've not double-checked it but I'm pretty sure that's correct. | 13:45.01 |
| paulgardiner | tor8, Robin_Watts: Sorry, taken me all this time to get my phone back to a state where I could work on these problems, and now I just tried a search and CR did provoke it into action. | 13:54.52 |
| | I guess it varies from one device to another. There's a fix I can try, but obviously I can't test it. | 13:55.51 |
| Robin_Watts | sebras: It would have to be in the java side. | 14:06.28 |
| paulgardiner | tor8, Robin_Watts: I've pushed a change to master on my casper repo. | 14:10.22 |
| Robin_Watts | paulgardiner: Will try that in a mo. | 14:11.50 |
| | oooh. | 14:14.12 |
| | http://pastebin.com/TdwnkMyw | 14:15.36 |
| | The first sign of a crash was around line 55ish. | 14:16.06 |
| | I think the problem is we're running out of AsyncTask slots. | 14:16.34 |
| | We can probably cure it by putting the execute call in a try/catch block. | 14:17.53 |
| paulgardiner | How did you deduce that? | 14:21.04 |
| Robin_Watts | See line 71 of my paste | 14:21.18 |
| | Then read upwards. | 14:21.28 |
| | it looks to me like the: pool=128/128 queue=10/10 implies that we're full. | 14:21.48 |
| sebras | Robin_Watts: is it possible to wait for them to complete? | 14:22.01 |
| Robin_Watts | I was about to ask paulgardiner that - this is his bit of code, not mine - far too clever for me. | 14:22.21 |
| sebras | :) | 14:23.02 |
| paulgardiner | Difficult. The whole point in using them is avoid stalling the UI, which is exactly what will happen if you wait, assuming there is a way to wait. | 14:23.52 |
| Robin_Watts | paulgardiner: Well, if you're stupid enough to flood the system by clicking that many times, I think it's reasonable for the app to say "Just hold on a moment..." | 14:24.37 |
| | i.e. stalling in this extreme case doesn't seem so bad. | 14:24.59 |
| paulgardiner | Yeah true. But we don't want to wait unnecessarily. I wonder if we can count the outstanding ones. | 14:25.23 |
| Robin_Watts | and do what? | 14:25.33 |
| paulgardiner | Wait if more than so many outstanding... again assuming there is a way to wait. | 14:25.56 |
| Robin_Watts | boolean retry = false; do { try { sizingTask.execute(...); } catch (...) { retry = true; } } while (retry); ? | 14:27.02 |
| paulgardiner | Interesting. | 14:27.17 |
| Robin_Watts | The question is, should we ever actually have more than 1 of these things queued? | 14:27.43 |
| | I mean, we can only be "going to" 1 page at a time, right ? | 14:28.08 |
| | Can we cancel any outstanding ones (or at least any that have been requested but haven't started yet), and schedule a new one? | 14:28.44 |
| sebras | Another question is -- is there another place where AsyncTask is used where the app may start executing these on its own without the user clicking anywhere? if so it may spontaneously crash. | 14:28.52 |
| paulgardiner | We speculatively load pages around the current one. Also we cannot cancel tasks properly | 14:29.04 |
| | AsyncTask is used all over the place. | 14:29.23 |
| | Finding the page size, rendering to a bitmap, search... | 14:29.51 |
| Robin_Watts | AsyncTask is used for searching, and for sizing a new page, and twice in the rendering. | 14:29.53 |
| sebras | right. | 14:29.59 |
| Robin_Watts | (afaict) | 14:30.00 |
| tor8 | paulgardiner: the iOS app has a fair amount of trickery to cancel outstanding requests | 14:30.07 |
| paulgardiner | Yeah. That's it I think | 14:30.08 |
| Robin_Watts | all of which will be in response to clicks. | 14:30.16 |
| tor8 | but it basically amounts to aborting the request when it gets around to it, not removing them from the queue | 14:30.26 |
| sebras | ok, so that means that there are other situations where I can click like a maniac and end up with the same crash. | 14:30.54 |
| Robin_Watts | Rather than saying: "please execute size(pageNumber);" could we do: | 14:31.03 |
| paulgardiner | tor8: Yeah, I guess we should be signalling the library to give up on a render | 14:31.09 |
| Robin_Watts | "int nextPageToResize = n; int request outstanding = 1; "please execute size()" | 14:31.51 |
| | and then have the size function read nextPageToResize, and set outstanding to 0. | 14:32.13 |
| | That way on subsequent calls, we'd only ask for a new background event if one wasn't started yet. | 14:32.39 |
| | I'm explaining it badly. | 14:32.46 |
| paulgardiner | A still flawed but less annoying behaviour would result from just catching and ignoring the exceptions. | 14:37.54 |
| | And in the catch we could stick up a dialog box saying "Calm Down!!" :-) | 14:38.45 |
| Robin_Watts | OK. I have a fix, I think. | 15:12.00 |
| | If we get an exception trying to do the background task, we catch it, and do it in the foreground. | 15:12.35 |
| | I can clearly feel when we hit that point as the UI stalls. | 15:12.49 |
| tor8 | paulgardiner: have you got a patch for me to test on my device? | 15:12.50 |
| Robin_Watts | tor8: It's in his repo, I believe. | 15:13.24 |
| | <paulgardiner>tor8, Robin_Watts: I've pushed a change to master on my casper repo. | 15:13.53 |
| paulgardiner | tor8: for the Return-not-provoking-search problem, yes: last commit to master on my casper repo. | 15:13.57 |
| | Maintaining highlights across a device rotation is looking more complicated. | 15:14.36 |
| tor8 | paulgardiner: well, that one doesn't have to hold up 1.0 :) | 15:15.01 |
| paulgardiner | Ok. That's a relief. | 15:15.39 |
| tor8 | paulgardiner: better, but I wonder if it's possible to dismiss the keyboard at the same time | 15:18.09 |
| paulgardiner | Oh right. Possibly just needs a call to hideKeyboard() | 15:19.15 |
| Robin_Watts | tor8: Crashy fix posted. | 15:20.19 |
| | I'm going to go back to looking at mvrhel's stuff unless there is anything else I should look at. | 15:23.07 |
| debjan | Hi, I was wondering if mupdf viewer will support pdf bookmarks anytime soon? | 15:28.15 |
| Robin_Watts | debjan: We are preparing the 1.0 release now. This does not support bookmarks. | 15:30.04 |
| | The core code would support it, but the viewer hasn't got that functionality built in. | 15:30.41 |
| debjan | OK, thanks. That's what was hoping to see in new release, as I see lot of changes and thought to ask. Cheers | 15:31.42 |
| ray_laptop | morning, all | 15:46.21 |
| Robin_Watts | Morning ray_laptop | 15:46.38 |
| ray_laptop | are we having a meeting today ? | 15:46.51 |
| Robin_Watts | Henrys said no. | 15:47.03 |
| | (he's not here today anyway). | 15:47.10 |
| | He did say that had there been a meeting his only topic would have been to make people look back at the followup mail from the last meeting, and to look at the tasks they were assigned there. | 15:48.16 |
| | He hoped we'd all try to make some progress, or at least turn up prepared to talk about them at next weeks meeting. | 15:48.44 |
| henrys | I expected there would not be a meeting I just wanted to bring that up... sorry to be confusing. | 15:49.04 |
| paulgardiner | tor8, Robin_Watts: I have a fix for the search highlights disappearing on device rotation (again on casper) but now the hightlights aren't reset the moment one alters the text edit | 15:51.31 |
| | Having both features looks hard because the OS updates the edit text on device rotation. | 15:52.39 |
| Robin_Watts | Sorry, I'm confused here. We had it so that as soon as you typed in the search box the search highlights disappaeared? | 15:53.31 |
| paulgardiner | So far I cannot see a way to distinguish between the user altering the text and the OS reintroducing the pre-rotation state. | 15:53.38 |
| Robin_Watts | even before you hit return ? | 15:53.41 |
| paulgardiner | Robin_Watts: yes | 15:53.51 |
| henrys | you guys have gotten the agenda? Always paranoid it wasn't received when I don't get corrections. | 15:53.54 |
| Robin_Watts | Can you store both the highlights, and the search text used to generate them? | 15:54.15 |
| | Then when the text is reset, you only delete the highlights if the search text is different ? | 15:54.34 |
| paulgardiner | Ah. Nice idea. | 15:54.36 |
| Robin_Watts | henrys: Yes, I got it. | 15:54.55 |
| henrys | great and with that I'm out of here, have a good day! | 15:56.26 |
| Robin_Watts | henrys: have a nice day off, and a safe flight. | 15:56.44 |
| ray_laptop | it's been 4 days since my laptop last crashed (up until 10 minutes ago). | 15:57.42 |
| | henrys: just put something really controversial in the agenda and you might hear back ;-) | 15:58.24 |
| Robin_Watts | ray_laptop: I'd have put the thing through a wall by now. | 15:58.38 |
| ray_laptop | it does get frustrating. I have a maintenance contract on it, but IME sending something intermittent in is a waste of time. The technicians just run a standard test and then say "it passes all the tests" and send it back :-( | 16:00.36 |
| Robin_Watts | So.. ensure that it will not pass the tests before you send it. | 16:00.59 |
| | ray_laptop: mains across random jumpers on the motherboard should do the trick. | 16:01.34 |
| | mvrhel_laptop: Hi. | 16:01.40 |
| mvrhel_laptop | good morning Robin_Watts | 16:01.51 |
| Robin_Watts | I found the "missing braces" thing. | 16:01.52 |
| mvrhel_laptop | oh good | 16:01.58 |
| | I looked and looked at that thing | 16:02.02 |
| | and could not see what I was missing | 16:02.11 |
| Robin_Watts | In the #define cls_initial_values, after { gx_no_color_index, gx_no_color_index } | 16:02.24 |
| | you have {0 , 0} | 16:02.30 |
| | where that is supposed to be an array of 2 device colors. | 16:02.51 |
| | device colors are structures, that start with a pointer. | 16:03.03 |
| | So you want something like { {NULL}, {NULL} } | 16:03.19 |
| mvrhel_laptop | ah yes | 16:03.29 |
| | ok. thanks | 16:03.35 |
| Robin_Watts | I can reproduce the first SEGV here too. | 16:03.46 |
| | but I am still looking for what causes it. | 16:03.53 |
| marcosw | are we meeting today? | 16:04.00 |
| Robin_Watts | (It's within tile_by_steps inside the clist stuff, doing a clip_copy_planes) | 16:04.20 |
| | marcosw: Nope. | 16:04.23 |
| marcosw | :-( | 16:04.32 |
| Robin_Watts | marcosw: Would you like a meeting? | 16:04.43 |
| mvrhel_laptop | ok. unfortunately, the rendering issue I am looking at is a strange one with the pdf14 pop device compositor action not making it during the clist playback | 16:04.44 |
| | it is getting put in but I never see it during playback and so we end up with a white page | 16:05.05 |
| | I can't understand how my changes could affect this | 16:05.19 |
| marcosw | no, but I was actually on time for once. | 16:05.27 |
| Robin_Watts | marcosw: ha! | 16:05.36 |
| paulgardiner | Robin_Watts: Yep that worked thanks. I've pushed a final version to casper | 16:08.18 |
| Robin_Watts | Fab. | 16:08.26 |
| | mvrhel_laptop: So the problem with this SEGV looks to be that in tile_by_steps/tile_colored_fill I have a tile that is 477x197 and 1 plane deep. (But with a raster of 1908, which is consistent with 32bits of data per pixel) | 16:11.17 |
| | and by the time it gets to mem_planar_copy_planes, we're trying to copy 4 planes of data. | 16:11.36 |
| mvrhel_laptop | oh | 16:11.37 |
| | is there transparency in this file? | 16:12.02 |
| | Robin_Watts: I am wondering if the pdf14 device is doing some of its changing color spaces and causing issues | 16:12.33 |
| Robin_Watts | how would I know? | 16:12.40 |
| mvrhel_laptop | hehe | 16:12.42 |
| ray_laptop | marcosw: hard to be late for a meeting that isn't happening ;-) | 16:12.44 |
| mvrhel_laptop | run with -Zv | 16:12.57 |
| | which file is this? | 16:13.13 |
| Robin_Watts | I've got it stopped in the debugger. Can I look for a particular device? | 16:13.15 |
| | tests/pdf/Bug6901014_org_chromium_ANn03F.pdf.psdcmyk.300.1 | 16:13.25 |
| mvrhel_laptop | look at the target device? | 16:13.34 |
| Robin_Watts | I can't see pdf14 anywhere in the stack'o'devices | 16:14.13 |
| mvrhel_laptop | ok | 16:14.16 |
| | that is odd then | 16:14.21 |
| ray_laptop | the raster is calculated from the color_info, right ? | 16:14.26 |
| mvrhel_laptop | is it a pattern mask? | 16:14.32 |
| ray_laptop | Robin_Watts: what device is on top ? | 16:14.42 |
| mvrhel_laptop | oh this file has no transparency | 16:15.20 |
| ray_laptop | steps out to let just mvrhel_laptop ask the questions (sorry) | 16:15.34 |
| Robin_Watts | http://pastebin.ca/2139783 call stack, in case that helps. | 16:16.27 |
| | oh, I see tile_by_steps in the callstack twice. That's always a sign of insanity. | 16:18.34 |
| mvrhel_laptop | hmm. is the pattern a clister if you want to pass on this one that is fine. After I track down this missing pdf14pop device issue I will focus on this issue. It is | 16:20.47 |
| Robin_Watts | mvrhel_laptop: I'll prod at it for a few minutes more, but then I'll park it and look at the next. | 16:21.22 |
| mvrhel_laptop | ok thanks | 16:21.32 |
| | is the pattern a clist? | 16:21.42 |
| Robin_Watts | No one has ever in the history of the world needed a cup of tea as much as I do now. brb. | 16:21.54 |
| | yes. | 16:21.55 |
| mvrhel_laptop | :) | 16:23.23 |
| | It would be interesting to compare this one to the trunk at this same break point | 16:23.48 |
| | now back to my missing pdf14 pop | 16:24.07 |
| Robin_Watts | tor8: paulgardiner just rang to say he didn't put the hidekeyboard() call in, and he's now cooking. | 16:34.08 |
| | I'll take care of that if you want. | 16:34.22 |
| | Done, and both commits pushed to master. | 16:44.45 |
| | Seem to work fine here. | 16:44.51 |
| mvrhel_laptop | ray_laptop: did you push your changes to the soft mask size ? | 16:45.20 |
| | I can look at the logs... | 16:46.43 |
| ray_laptop | mvrhel_laptop: I thought I had, but I only see it locally | 16:46.46 |
| mvrhel_laptop | ok | 16:46.58 |
| | I guess I need to compare this thing to the trunk | 16:47.50 |
| | very weird. in the first band, its last compositor action is a soft mask push | 16:48.31 |
| | and then we move on to the next band with a pdf14 device push | 16:48.49 |
| | oh unless this is a pattern | 16:48.53 |
| | hmm | 16:49.25 |
| ray_laptop | mvrhel_laptop: should I go ahead and push the (one line) change ? | 16:49.44 |
| mvrhel_laptop | ray_laptop: if you can hold off I would appreciate. | 16:50.02 |
| ray_laptop | - if ( pdf14pct->params.GrayBackground == 1.0 ) { | 16:50.24 |
| | + if ( pdf14pct->params.GrayBackground == 1.0 || pdf14pct->params.mask_is_image) { | 16:50.25 |
| mvrhel_laptop | I am right in the middle of this compositor queue stuff. | 16:50.26 |
| | and trying to compare my stuff to the trunk | 16:50.37 |
| ray_laptop | mvrhel_laptop: no problem -- I have it safely on a branch | 16:50.39 |
| mvrhel_laptop | thanks | 16:50.43 |
| ray_laptop | mvrhel_laptop: when I ran cluster on it the frist time there were 7 diffs, then I (by mistake) ran it again with bmpcmp. The second run showed only 4 diffs and bmpcmp showed 'no differences'. Strange | 16:51.52 |
| Robin_Watts | I cannot explain why sometimes the cluster detects differences and yet bmpcmp finds none :( | 16:52.40 |
| mvrhel_laptop | header diffs? | 16:53.08 |
| | although not in ppm | 16:53.42 |
| ray_laptop | Robin_Watts: how about the 7 diffs, then 4 diffs (with no diffs in common) on cluster runs about 1 hour apart. | 16:53.50 |
| Robin_Watts | indeterminisms? | 16:54.13 |
| ray_laptop | Robin_Watts: that is a rhetorical question | 16:54.22 |
| Robin_Watts | mvrhel_laptop: Next one is easier to understand - overprint_device has no copy_planes proc entry :) | 16:59.24 |
| mvrhel_laptop | aha | 16:59.39 |
| Robin_Watts | copy_color and copy_alpha seem to be defaults for the overprint_device. So presumably copy_planes should be too ? | 17:00.41 |
| mvrhel_laptop | if that is true, then yes. If you want to add that in, that would be fine | 17:01.05 |
| tor8 | Robin_Watts: anything else before I tag 1.0? | 17:05.27 |
| Robin_Watts | tor8: To the best of my knowledge, no. | 17:05.45 |
| tor8 | Robin_Watts: okay. 1.0 tagged, compiled, uploaded and announced on the news page. | 17:22.03 |
| Robin_Watts | tor8: Wow, that was fast. | 17:22.16 |
| | Have you done the android build too? and ios builds? | 17:22.32 |
| | I'm assuming you didn't upx the windows binaries then, cos that takes a while :) | 17:22.51 |
| tor8 | not ios, that'll have to wait. I may do that on the trip to london. | 17:23.00 |
| | no, I don't really see the point of upx:ing it. just going to slow down startup times. | 17:23.15 |
| Robin_Watts | Fair enough. | 17:23.32 |
| | tor8: When do you arrive in London ? | 17:25.09 |
| | Copyright statement on mupdf.com should probably say 2006-2012 now. | 17:26.25 |
| tor8 | Robin_Watts: 17:25 at T5 | 17:26.36 |
| Robin_Watts | I'll be getting to the hotel probably around the same time as you then. | 17:28.26 |
| tor8 | shall we meet up and head out for dinner? | 17:28.56 |
| Robin_Watts | yeah, not sure where there is to eat, but I'm sure we can find something. I'll have the car. | 17:29.16 |
| tor8 | Robin_Watts: copyright statements amended, thanks for pointing them out | 17:31.02 |
| Robin_Watts | np. | 17:31.14 |
| paulgardiner | tor8, Robin_Watts: nothing else disasterous showed up with the android app? | 17:49.59 |
| Robin_Watts | paulgardiner: Don't think so. I hope not now :) | 17:50.15 |
| paulgardiner | Ah. You've tagged. Woo hoo! | 17:50.50 |
| tor8 | \o/ but with my luck disaster will strike soon! | 17:51.18 |
| Leper | so I just installed mupdf 1.0 on my kindle fire; so far so good, but I do have a question about mupdf on android in general... are the menu and search android buttons supposed to work? | 18:03.52 |
| Robin_Watts | No. | 18:04.17 |
| Leper | any particular reason? it'd be sorta nice if they did, even if they were redundant to the app buttons | 18:04.49 |
| Robin_Watts | (Why do people come up with these obvious suggestions seconds after the release? :/ ) | 18:05.02 |
| | It would indeed be nice. | 18:05.24 |
| Leper | heh, sorry, I actually didn't even realize you guys were releasing today, I just totally happened to stumble on it by accident | 18:05.32 |
| | anyway, the important thing is that it works, and actually has the menu/link index | 18:06.41 |
| | I sorta wish the landscape mode would automatically fit-to-width... but that's probably more a matter of taste | 18:07.33 |
| Robin_Watts | mvrhel_laptop: I pushed a fix for the overprint not having copy_planes | 18:09.33 |
| | The next SEGV is down to pinst == NULL in gx_pattern_load | 18:10.00 |
| mvrhel_laptop | hmm. I have seen that one before | 18:10.20 |
| | this compositor queue issue is weird | 18:10.38 |
| | comparing now step by step to the trunk for the first band. first band queue ends in the middle of soft mask | 18:11.05 |
| Robin_Watts | I'm gonna skip this one. | 18:11.41 |
| mvrhel_laptop | Robin_Watts: ok thanks | 18:12.03 |
| | ugh. I am thinking I must be corrupting the clist some how | 18:12.32 |
| | this is going to boil down to looking at the clist memory buffer as it is written | 18:13.20 |
| | basically need to look for an end mask compositor action getting corrupted | 18:14.57 |
| | and this file seems to have a load of soft masks | 18:15.10 |
| Robin_Watts | mvrhel_laptop: Dumb question, but can you cut the file down to something smaller and still have it crash ? | 18:16.26 |
| mvrhel_laptop | I should try that. I wish it were a crash. It runs along and I get nothing rendered due to the fact that it never receives a pop for the pdf14 device | 18:17.28 |
| | however the compositor queue fails way before that | 18:17.41 |
| | during the reading it is missing a bunch of stuff. | 18:18.01 |
| marcosw | mvrhel_laptop: you might want to pack an umbrella, we have thunderstorms predicted for tomorrow | 18:18.10 |
| sebras | 1.0! yey! :) | 18:18.13 |
| mvrhel_laptop | marcosw: I dont own an umbrella | 18:18.27 |
| | we don't use them here | 18:18.38 |
| | that is how we tell who is a tourist | 18:18.49 |
| sebras | btw I remember pointing out to tor8 that the menu button didn't do anything last night... ;) | 18:18.51 |
| marcosw | unusual, considering where you live :-) | 18:18.53 |
| | just jackets with rain hoods? | 18:19.02 |
| mvrhel_laptop | yes | 18:19.07 |
| | ok. so I probably need to focus on the new clist commands that I added | 18:19.56 |
| Robin_Watts | The next one is the same issue as the first one (tile with 1 plane and 32bits rather than 4 planes of 8 bits) | 18:22.32 |
| ray_laptop | Robin_Watts: did you see the files from Tsutomu-san (and the second email with the .zip password) ? The 100 page job is just the same (JEITA J6) page over and over again. It uses two Japanese fonts (not embedded) | 18:31.40 |
| Robin_Watts | I did, but I haven't looked yet. | 18:32.37 |
| ray_laptop | Robin_Watts: np. I did some looking into them and am replying. I am curious as to what timings you will see on your ARM. | 18:33.41 |
| mvrhel_laptop | aha!. caught the sucker | 18:33.41 |
| ray_laptop | hopes it wasn't something bonehead I did | 18:34.03 |
| mvrhel_laptop | hmm. hold on | 18:34.44 |
| | ray_laptop: where is a breakpoint that I can set, where the clist writing buffer is emptied. I want to make sure I am not just stumbling upon a case where it is getting flushed and refilled | 18:36.19 |
| ray_laptop | mvrhel_laptop: sorry -- I was finishing an email | 18:49.54 |
| mvrhel_laptop | no worries. now I think my earlier excitement was not justified | 18:50.29 |
| | it seems to be writing the clist compsitor action in just fine | 18:50.50 |
| ray_laptop | mvrhel_laptop: do you want the place where the 'final' writing happens ? clist_close_writer_and_init_reader | 18:51.02 |
| mvrhel_laptop | well, when does it flush and reuse the clist writing buffer? Isnt if filled at some point during writing, and the written out to disk? | 18:51.40 |
| | and the buffer is reused for additional stuff? | 18:51.49 |
| | still in the writing stage? | 18:52.01 |
| ray_laptop | when the buffer is filled, it calls cmd_write_buffer in bxclutil.c | 18:52.15 |
| | s/bxgx/ | 18:52.27 |
| | gxclutil.c (can't type today) | 18:52.41 |
| mvrhel_laptop | ok great | 18:52.54 |
| | ok. so the writing phase is fine | 18:53.16 |
| | it was during the reuse of the buffer that the memory was changing. | 18:53.34 |
| | so, things *must* be going wrong during the reading phase | 18:53.50 |
| | need to catch it at that end. | 18:54.03 |
| | unfortunately, need to go grab some lunch and then get ready for my trip | 18:54.30 |
| ray_laptop | mvrhel_laptop: OK. Just call if you want to talk about any of it. Have a good trip. | 18:54.59 |
| mvrhel_laptop | ok. thanks | 18:55.05 |
| ray_laptop | Robin_Watts: let me know if you have any ideas after you see my email response to Tsutomo-san | 18:56.14 |
| | (for the logs) mvrhel is probably getting messed up by the compositor queue not being processed correctly (but that's just a random guess) | 20:04.42 |
| | another possibility is that the compositor command is not getting written to the enough bands due to a bbox issue | 20:07.01 |
| Robin_Watts | ray_laptop: Right. I got back into my beagleboard. | 20:18.25 |
| ray_laptop | ii.e., if we write the 'push_device' to more bands than we write the 'pop_device' to. | 20:18.26 |
| Robin_Watts | and I ran the larger of those PS files through the pspcl6 exe I had on it. | 20:18.40 |
| | I only have a limited subset of devices on that build. | 20:19.11 |
| ray_laptop | Robin_Watts: I don't suppose you have those particular CIDFonts laying around, do you (Ryumin-Light and GothicBBB-Medium) | 20:19.18 |
| Robin_Watts | I do not knowingly have any cidfonts | 20:19.30 |
| | but... the startup time should be the same regardless, right? | 20:19.55 |
| | % Outputpage start time = 1.01544, memory allocated = 3691864, used = 3585466 | 20:20.51 |
| | % done : time = 1, pages = 1 | 20:20.53 |
| | % Outputpage end time = 1.01608, memory allocated = 3691864, used = 3585466 | 20:20.54 |
| | % Outputpage start time = 1.12222, memory allocated = 3829316, used = 3732650 | 20:20.57 |
| | %%[ PrinterError: font not found ]%% | 20:20.58 |
| | % done : time = 1.1, pages = 2 | 20:21.00 |
| | % Outputpage end time = 1.12265, memory allocated = 3829316, used = 3732650 | 20:21.01 |
| ray_laptop | Robin_Watts: without the cidfmap and a substitute CIDFont you will just get one page. Yes the init time is the same, but the font loading time and processing time to render the first page won't correspond to the J6 page | 20:22.51 |
| | Robin_Watts: what is you 'Start time' | 20:23.14 |
| Robin_Watts | ? | 20:23.29 |
| ray_laptop | that is the time for initialization prior to any processing of the input file (or error page) | 20:23.51 |
| Robin_Watts | I ran with -Z: and what you see there are the only outputs I got | 20:24.09 |
| ray_laptop | Robin_Watts: you should see a line before the first Outputpage start time that looks like: % Start time = 0.082, memory allocated = 1553816, used = 1399426 | 20:24.49 |
| Robin_Watts | Nope. | 20:25.16 |
| | but maybe that's because I'm using pspcl6 ? | 20:25.24 |
| | Let me try and build a vanilla gs. | 20:25.30 |
| ray_laptop | Oh. You need to use ghostscript | 20:25.39 |
| | the init time for pspcl6 will be different anyway (slower because it also starts PJL and PCL) | 20:27.09 |
| ray_laptop | builds release pspcl6.exe to see what I get for -Z: | 20:30.14 |
| | Robin_Watts: the print_resource_usage for the 'Start time' is in gs_main_init2 which _should_ be called with pspcl6. Unless the gs_debug_c flag isn't set yet | 20:31.58 |
| | if we are initializing the parser before the gs_debug flags are set, then there will be options that don't work correctly | 20:33.15 |
| | Robin_Watts: you should have the msmincho.ttc and msgothic.ttc in your /Windows/Fonts directory | 20:34.37 |
| Robin_Watts | ray_laptop: I may do, but I don't have a clue what to do with them. | 20:38.53 |
| ray_laptop | Robin_Watts: put them into your CIDFont directory and mkromfs should pick them up. Then modify the cidfmap (in Resource/Init) and change the /Path to (%%romesource/CIDFont/msmincho.ttc) | 20:40.26 |
| | darn that is supposed to be (%rom%Resource/CIDFont/msmincho.ttc) | 20:41.00 |
| | modifying the cidfmap lines I had in the email | 20:41.50 |
| chrisl_r61 | Robin_Watts, ray_laptop: remember we build in a TTF suitable for CID substitution now. | 20:43.55 |
| ray_laptop | chrisl: really ? how come I still get the error unless I do the explicit cidfmap ? | 20:46.35 |
| | if it is droidsansfallback, where is it (not in my tree) | 20:47.11 |
| chrisl_r61 | ray_laptop: we can't automatically substitute in PS files (not enough info) but the TTF file is still in the romfs | 20:47.12 |
| ray_laptop | chrisl: where is it in the sources ? | 20:47.33 |
| chrisl_r61 | ray_laptop: it's in Resource/CIDFSubst | 20:47.33 |
| | So. using something like %romesource/CIDFSubst/DroidSansFallback.ttf in your cidfmap entry should use it. | 20:48.20 |
| ray_laptop | chrisl: I'll try that | 20:48.32 |
| chrisl_r61 | Ugh, stupid IRC - you see what I mean, though..... | 20:48.44 |
| ray_laptop | but since the original file had two different CIDFonts, using the same font for both would make the timings different (one less font to load) | 20:49.05 |
| | unless the customer comes back and tells us that he is using a single substitution for both | 20:49.34 |
| | chrisl: yeah, I did the same thing when I typed to Robin_Watts | 20:49.56 |
| chrisl_r61 | True, but it probably makes life *much* easier for Robin_Watts on the ARM board (using a built in font file) | 20:50.01 |
| ray_laptop | building with the ms*.ttc files in the Resource/CIDFont (or Resource/CIDFSubst) directory shouldn't be that hard | 20:51.12 |
| chrisl_r61 | ray_laptop: actually, I'm not sure it will affect the timings - we have to "create" a CIDFont to use, which is different for each substitution. | 20:51.42 |
| ray_laptop | chrisl: it depends on where the time is being spent | 20:52.30 |
| chrisl_r61 | The point is, I think we're still effectively loading two fonts, even though we'd happen to be substituting the same TTF twice. | 20:53.29 |
| ray_laptop | chrisl: I see. point taken. But droidsansfallback probably has a LOT more glyphs than msmincho or msgothic | 20:54.23 |
| | since it encompasses a larger language set | 20:54.39 |
| chrisl_r61 | Well, it's up to Robin_Watts how much trouble he wants to go to. | 20:55.45 |
| Robin_Watts | OK, I've just got gs built I hope. | 20:56.33 |
| ray_laptop | I'm pretty sure the "real" Ryumin-Light and GothicBBB are Morisawa | 20:57.18 |
| | Robin_Watts: with what for the Asian fonts ? | 20:57.43 |
| Robin_Watts | Damn. | 20:57.52 |
| | No, I'm just trying to build the latest gs for the beagleboard. | 20:58.12 |
| | but the cross compilation didn't work :( | 20:58.36 |
| ray_laptop | Robin_Watts: OK -- so you can try the cidfmap that chrisl mentioned that points the /Path to (%rom%Resource/CIDFSubst/DroidSansFallback.ttf) | 20:59.21 |
| Robin_Watts | ray_laptop: Will do. | 20:59.53 |
| ray_laptop | Robin_Watts: Note that if it isn't a ttc (collection) you need to remove the SubfontId 1 | 21:00.15 |
| chrisl_r61 | Robin_Watts: we haven't changed much with the build since you last built for the BB, have we? | 21:00.32 |
| | DroidSansFallback isn't a ttc, just a ttf | 21:00.53 |
| Robin_Watts | chrisl_r61: Probably not. | 21:00.56 |
| chrisl_r61 | Robin_Watts: I'm just trying to think if I've done anything to break it..... | 21:01.21 |
| ray_laptop | which is why I mentioned removing the "SubfontID 1" | 21:01.53 |
| Robin_Watts | chrisl_r61: No, it was my own stupid fault. | 21:01.56 |
| ray_laptop | goes to try the DroidSansFallback | 21:02.18 |
| | Thiis worked for me: | 21:05.53 |
| | Ryumin-Light << /FileType /TrueType /Path (%romesource/CIDFSubst/DroidSansFallback.ttf) /CSI [(Japan1) 2] >> ; | 21:05.56 |
| | /GothicBBB-Medium << /FileType /TrueType /Path (%romesource/CIDFSubst/DroidSansFallback.ttf) /CSI [(Japan1) 2] >> ; | 21:05.57 |
| | oops: | 21:06.23 |
| | Ryumin-Light << /FileType /TrueType /Path (%rom%Resource/CIDFSubst/DroidSansFallback.ttf) /CSI [(Japan1) 2] >> ; | 21:06.24 |
| | /GothicBBB-Medium << /FileType /TrueType /Path (%rom%Resource/CIDFSubst/DroidSansFallback.ttf) /CSI [(Japan1) 2] >> ; | 21:06.26 |
| chrisl_r61 | ray_laptop: how do you get IRC to not swallow the per cent stuff? | 21:07.04 |
| ray_laptop | chrsl: to have it show as %R your need to type % % R (no spaces) | 21:08.37 |
| chrisl_r61 | Oh, thanks - will try to remember that..... | 21:08.59 |
| Gigs- | Does tiffsep support more than 8 colors now? | 21:09.27 |
| ray_laptop | the magic chatzilla codes following a % are U B R O and C | 21:09.40 |
| | Gigs: it has for a while (with the 'compressed color encoding') which is in the default build. With mvrhel's changes, it will do it faster and better (no funky color encoding) | 21:10.48 |
| Gigs- | I was using SeparationOrder with multiple passes and recently upgraded to 9 | 21:11.15 |
| ray_laptop | Gigs: but mvrhel's changes aren't posted anywhere yet | 21:11.28 |
| Gigs- | well I'm OK with slower | 21:11.43 |
| | the new behavior has caused a regression with my scripts | 21:12.06 |
| | I'm not sure exactly what the problem is yet | 21:12.17 |
| ray_laptop | Gigs: the problem with compressed color encoding is that you can get a 'rangecheck in showpage' if there are more colors altogether than we can smash into a 64-bit value. | 21:12.33 |
| Gigs- | how many bits does each color take? | 21:13.01 |
| ray_laptop | Gigs: with compressed color encoding, it is hard to say. | 21:13.40 |
| Gigs- | what exactly are you encoding? | 21:13.48 |
| ray_laptop | there are 8-bits of color for CMYK and the spot colors, but the encoding gets clever and includes some mapping that doesn't put channels in that have value 0 (no ink) and also combines channels that all have the same value. | 21:15.23 |
| Gigs- | so if we have 9 separations that have actual data on them then it will still require mult-pass | 21:16.24 |
| ray_laptop | Gigs: no. we have people that have done 252 spot color pantone color sheets (all on a single page) in a single pass | 21:17.20 |
| Gigs- | we never have more than maybe 10 | 21:18.57 |
| ray_laptop | Gigs: see the comment in base/gdecdevn.c before the function devn_encode_compressed_color | 21:19.01 |
| | Gigs: but that will all be going away once Michael Vrhel finishes his "planar spot color' modifications (probably this week) | 21:19.44 |
| | Gigs: and then we will be able to do any number of spot colors in any number of combinations (up to the compile time limit set by base/gsccolor.h:# define GS_CLIENT_COLOR_MAX_COMPONENTS | 21:21.26 |
| Gigs- | well let me tell you what I'm doing now and what I'm seeing | 21:21.37 |
| ray_laptop | (current default in the build is 14, but we may change that) | 21:21.44 |
| Gigs- | I suppress any colorant named "Varnish" or "Die" and build a composite | 21:22.06 |
| | then I get the list of colorant names and do multiple passes with separationorder | 21:22.31 |
| | for some reason Varnish is coming up blank in the separated output now | 21:22.46 |
| | it's probably technically a bug in my scripts somewhere but it worked before (tm) | 21:23.01 |
| ray_laptop | Gigs: that works fine for everything but the CMYK planes. The problem is that overprint won't be correct if a separation is being ignored (AIUI) | 21:23.43 |
| | and the CMYK composite won't be correct unless it has all of the separations. | 21:24.13 |
| | but with compressed color encoding, giving it more than 8 colors in the SeparationOrder list should be fine (with 9.05) unless we encounter the problem of colors that we can't encode | 21:25.27 |
| Gigs- | why would the overprint need separations not involved in the said overprinting | 21:26.21 |
| ray_laptop | and it is very rare to find files that have color combinations that are too comlex. Transparency is usually the "gotcha" | 21:26.29 |
| Gigs- | well let me back up, our "Varnish" and "Die" separations are not even really part of the image | 21:26.59 |
| | they are really metadata that probably shouldn't be in the file in the first place | 21:27.14 |
| ray_laptop | Gigs: if overprint is false, then drawing to a separation is supposed to erase other channels/colorants (depending on PDF OverprintMode (OM)) | 21:27.48 |
| | there is one overprintMode that causes channels that have value == 0.0 to be left unchanged rather than erased. | 21:29.26 |
| Gigs- | well let me take out the multipass code and see if my issue goes away | 21:31.08 |
| ray_laptop | oops that is "OPM" (not OM) in PDF's Graphics State parameter if OPM == 1 then tint values of 0.0 are ignores | 21:35.12 |
| | Gigs: sometimes creators have a full page rectangle fill with the "Varnish" color and don't have a valid tint transform and it makes everything black in the composite CMYK, or sometimes they don't have /OP true or /OPM in the graphics state and that can end up erasing everything else | 21:39.45 |
| Gigs- | yeah it's almost always the case | 21:40.06 |
| | which is why I need to suppress it | 21:40.10 |
| | for the full color composite | 21:40.34 |
| | but then I have to go back and render it alone | 21:40.39 |
| | for the separated output | 21:40.47 |
| | I think that may be what happened | 21:41.54 |
| ray_laptop | Gigs: rather than do that, if you have a specific set of names you want to handle a certain way, it would be easier to modify the PDF interpreter | 21:42.00 |
| Gigs- | I think it used to not even produce files for colorants missing in separationorder, and now it does produce blank ones | 21:42.23 |
| | I think that's what causing my bug | 21:42.37 |
| | I can work around that though | 21:42.48 |
| ray_laptop | if the separation name is (Varnish) then use a forced harmless tinit transform and make sure that OPM is 1 | 21:43.01 |
| Gigs- | I try to avoid maintaining patches for ghostscript | 21:43.35 |
| ray_laptop | I have to pick my son up from school. bbiaw. | 21:45.18 |
| Gigs- | thanks | 21:45.23 |
| | http://pastebin.ca/2139894 | 21:59.57 |
| | this produces a very large and very blank file named 32058-buildtiffs_3 and no .s0.tif or any separation | 22:00.49 |
| Robin_Watts | ray_laptop: For the logs. I got new gs building for the beagleboard. % Start time = 0.328918, memory allocated = 2872168, used = 2694995 | 23:01.13 |
| | That's vanilla gs. I'll try updating the cid stuff tomorrow. | 23:01.34 |
| | In fact I've done the cidfont stuff now (falling back to droidsans). | 23:06.19 |
| | % Start time = 0.327757, memory allocated = 2852072, used = 2689670 | 23:06.32 |
| | % Outputpage start time = 2.88888, memory allocated = 7040248, used = 6676532 | 23:07.05 |
| | % Outputpage end time = 2.88956, memory allocated = 7040248, used = 6676532 | 23:07.07 |
| | % Final time = 12.6037, memory allocated = 6861316, used = 6366527 | 23:07.20 |
| | That's for: ./gs -Z: -o /dev/null -sDEVICE=ppmraw J6_100P_FontDev_Auto.ps | 23:07.50 |
| | Forward 1 day (to 2012/04/25)>>> | |
IRC Logs