| | <<<Back 1 day (to 2013/02/28) | 2013/03/01 |
| Robin_Watts | mvrhel_laptop: ping | 00:13.26 |
| | mvrhel_laptop: No, the last commit to golden was not in december | 00:14.49 |
| mvrhel_laptop | Robin_Watts: I got the most recent commits | 00:21.57 |
| Robin_Watts | ah, cool. | 00:22.05 |
| mvrhel_laptop | but for some reason I had to pull them from my origin on casper | 00:22.11 |
| | pulling them from golden didnt work | 00:22.19 |
| | at least with tortoise git | 00:22.30 |
| Robin_Watts | Right. Does tortoise git show the commands it actually sends? You should be doing the equivalent of "git pull --rebase golden master" | 00:23.02 |
| mvrhel_laptop | anyway, trying to figure out how best to pull everything new into my branch and also to make sure the branch is on my repos on caspar | 00:23.09 |
| Robin_Watts | ok, so you've got the commits in your local repo on master. | 00:23.33 |
| | You should change to your branch (git checkout win8) (or whatever it's called) | 00:23.55 |
| mvrhel_laptop | my local repo is up to date, plus I have a branch that is not rebased locally | 00:23.56 |
| Robin_Watts | then: git rebase master | 00:24.04 |
| | or however you do that in tortoise. | 00:24.24 |
| mvrhel_laptop | ok. I am in the middle of some code rework. let me remove this stuff first | 00:24.45 |
| Robin_Watts | (git stash :) ) | 00:25.01 |
| mvrhel_laptop | ok so I am on the branch | 00:25.47 |
| | ah ok. I see let me rebase this to master | 00:26.33 |
| | of course I have a conflict with sln | 00:26.55 |
| | that is going to be a tricky one, as the solution with the windowRT stuff is going to have to be for VS 20q2 | 00:27.19 |
| | 2012 | 00:27.20 |
| | perhaps I need to have 2 solutions | 00:27.34 |
| Robin_Watts | perhaps, yes. | 00:27.46 |
| | we have a win32 dir with the win32 solution in. | 00:28.13 |
| | Perhaps a WinRT dir? or a win8 dir? | 00:28.22 |
| | That might be the easiest way to avoid you going insane. | 00:28.34 |
| mvrhel_laptop | perhaps. I guess I should probably do that first | 00:28.38 |
| | let me fix all of that first. I do see how to do the rebase for my branch | 00:29.08 |
| Robin_Watts | OK. "git rebase --abort" (or the tortoise equivalent) will go back to as you were. | 00:29.19 |
| mvrhel_laptop | yes. I aborted just now | 00:29.27 |
| Robin_Watts | How many commits on this branch? | 00:29.32 |
| mvrhel_laptop | one :) | 00:29.37 |
| | the initial one | 00:29.41 |
| Robin_Watts | OK. So nice and simple - you move the solution to the new dir, add it, and then unstage the old one so it's unchanged. | 00:30.18 |
| mvrhel_laptop | oh great idea | 00:30.33 |
| Robin_Watts | git is very nice in that you can go back and rewrite history, so we could have made this work even if you'd had a series of commits, but that's more complex of course. | 00:30.53 |
| mvrhel_laptop | let me attempt this | 00:31.04 |
| | so I need to undo the changes that I have in win32 now | 00:32.17 |
| Robin_Watts | yeah, by command line you do: "git reset --mixed HEAD~1 -- pathname" | 00:34.58 |
| | but it's probably easier with tortoise. | 00:35.17 |
| mvrhel_laptop | well we will see. luckily I do have a backup | 00:35.35 |
| Robin_Watts | Copy the files to win8 before you try reverting them (he says, stating the obvious) | 00:37.40 |
| mvrhel_laptop | Robin_Watts: Yes. I did that. Somehow something has gotten a little messed up here | 00:41.24 |
| | let me see if I can get the branch up to date now and then I will add in my minor changes to the fitz headers (the c++ stuff) | 00:42.00 |
| Robin_Watts | remember that at any stage you can do a hard reset to get back to your last commit. But that will throw away all your changes! | 00:42.24 |
| mvrhel_laptop | right. now I should be safe with the hard reset since it all is in another folder | 00:42.46 |
| | except for the header file changes. those are tiny though | 00:42.59 |
| | so right now, I am going to get my branch in rebased as is with my master | 00:44.28 |
| | the master is at the commit from paul today | 00:44.47 |
| Robin_Watts | Sorry? Rebasing your branch on master will give problems because of the .sln. | 00:45.38 |
| mvrhel_laptop | ok it is now fastforwarded that is | 00:45.46 |
| | I meant fast forward sorry | 00:45.58 |
| | Now I will add in my new solution | 00:46.11 |
| Robin_Watts | ok. I'm confused, but if you're happy, that's the main thing :) | 00:46.37 |
| mvrhel_laptop | so far I think I have a handle on it. basically now the branch and my master are the same as the golden | 00:47.00 |
| | I am going to commit my changes now to the branch | 00:47.08 |
| | but first I am going to hack out the win32 stuff from this solution | 00:47.25 |
| | or maybe I should just leave it | 00:48.04 |
| | I can do that later | 00:48.14 |
| | if I want | 00:48.22 |
| Robin_Watts | ok, so are you sorted for now? | 00:53.57 |
| mvrhel_laptop | Robin_Watts: apparently some of the functions in mupdf have changed since I last update | 00:56.05 |
| | but I should be able to get this sorted | 00:56.12 |
| Robin_Watts | mvrhel_laptop: possibly. | 00:56.19 |
| mvrhel_laptop | e.g. fz_bound_page changed | 00:56.24 |
| Robin_Watts | Right. | 00:56.31 |
| | So 2 main changes. | 00:56.41 |
| | 1) fz_bbox has changed to fz_irect | 00:56.50 |
| mvrhel_laptop | oh ok | 00:57.09 |
| Robin_Watts | 1a) Various places that used to take an fz_bbox now take an fz_rect cos it cleans the interface up. | 00:57.25 |
| | 2) We now pass most rects and matrices by reference rather than by value. | 00:57.48 |
| | (so instead of passing fz_infinite_rect, you pass &fz_infinite_rect etc) | 00:58.03 |
| | Hopefully it should be a simple thing to fix (basically, you'll see a compilation failure/warning and the fix should be obvious) | 00:58.35 |
| mvrhel_laptop | right | 00:58.46 |
| Robin_Watts | If you get stuck, push your branch to your repo and mail me, and I'll pull the branch and fix it tomorrow. | 00:59.21 |
| mvrhel_laptop | ok thanks | 00:59.30 |
| | oh fz_bound_page returns a pointer. item 2 above... | 01:00.21 |
| | fz_scale too... | 01:01.04 |
| | oh fz_scale really changed | 01:01.47 |
| | ok I see | 01:02.13 |
| Robin_Watts | 2a) matrix operations now pass by reference too, sorry. | 01:03.17 |
| mvrhel_laptop | ok building once again | 01:09.40 |
| | Darn. ugly crash when I try to open a file :( | 01:11.13 |
| | well something to beat on tonight | 01:11.21 |
| | hmm. something likely wacky in the windows app file restriction.... wonder why that has come back up | 01:12.34 |
| | bbiaw to work on this more | 01:12.43 |
| | oh links I see from the customer. | 01:14.06 |
| | need to get that going too | 01:14.10 |
| Robin_Watts | yeah. If this becomes urgent, I can always go buy a windows 8 license. | 01:14.33 |
| | so I could help out if required. | 01:15.34 |
| | I guess we'd need a VS2012 too. | 01:15.43 |
| sebras2 | robin: did you read about zopflik? | 01:16.01 |
| Robin_Watts | no? | 01:16.28 |
| sebras2 | not sure it makes sense in mupdf or what licese is used, but it might be useful... | 01:16.46 |
| Robin_Watts | What is it? Professor Google is failing me. | 01:17.13 |
| sebras2 | robin: itc's on hn. ic'm having a hard time pasting the url from my phone. :v( | 01:18.12 |
| Robin_Watts | ah, right. It's a better zipper. | 01:19.03 |
| sebras2 | yes. and zlib compatible v(or so they sayb)... | 01:20.06 |
| Robin_Watts | Yes, it's perfectly possible. | 01:20.15 |
| | I used another 'better than zip' thing before, and I can't remember it's name offhand. | 01:20.38 |
| sebras2 | ah. like the jpegmini thing i saw on hn lately.. | 01:21.22 |
| Robin_Watts | I had a script to compress things several times, and used zipmix to pick the smallest (or something like that) | 01:21.23 |
| | I saw the "jpegmini does video" the other day. impressive. | 01:21.47 |
| sebras2 | did you see the debunking for the videon-case took? | 01:22.31 |
| Robin_Watts | Peregrines brother? | 01:23.27 |
| sebras2 | got to go. goodnight alla! | 01:23.36 |
| Robin_Watts | night. | 01:23.40 |
| mvrhel_laptop | good night | 07:11.06 |
| chrisl | kens: I'm struggling with the opdfread Postscript :-( | 08:43.48 |
| kens | Nothing new there | 08:49.37 |
| | Have you looked at the de-obfuscated version ? | 08:49.51 |
| chrisl | Unfortunately what's confusing me involves the job specific part :-( | 08:50.39 |
| | Let me e-mail you the file..... | 08:51.02 |
| kens | Oh, do you want to mail me a copy and I'll chat about it ? | 08:51.04 |
| | ROFL | 08:51.09 |
| chrisl | On its way :-) | 08:51.19 |
| kens | OK got it. | 08:51.38 |
| chrisl | So if you open that, and go to line 8188 | 08:51.56 |
| kens | 11 0 obj | 08:52.08 |
| chrisl | Yep, that dictionary references object 25, which is defined *after* object 11 | 08:52.47 |
| kens | Hmm, well that's legal in PDF :-) | 08:53.00 |
| | Yes I see its the encoding | 08:53.12 |
| chrisl | Similarly the FonDescriptor | 08:53.35 |
| kens | I 'think' that's OK because they aaren't dreferenced until the font is used, by which time they have been defined | 08:54.10 |
| | Certainly works OK in GS | 08:54.29 |
| chrisl | In this file font isn't used, but we still end up calling MakeType42...... | 08:54.44 |
| kens | Really ? THat's od | 08:54.54 |
| | Interesting | 08:55.25 |
| chrisl | If you have a search, it never references object 11 (I cut out the reference) | 08:55.29 |
| kens | Yes. | 08:55.42 |
| | Did you run this with PDFR_DEBUG ? | 08:55.49 |
| chrisl | Yes, not much help, really | 08:56.09 |
| kens | It says it 'recognised a font object' | 08:56.44 |
| | and from there proceeds to define the font | 08:56.52 |
| chrisl | Specifically, what I've been trying to fathom is how the "endobj" procedure knows that object 20 is a font file | 08:57.13 |
| kens | TypeDaemons recognises the object type, need to see where that is executed from | 08:57.43 |
| chrisl | from endobj | 08:58.49 |
| kens | yep | 08:58.56 |
| | So there you are, endobj executes RunTypeDameon which looks for the object type '/Font' and determines its a font | 08:59.24 |
| chrisl | Yes, but the dictionary contains references to as yet undefined objects...... | 09:00.04 |
| kens | True, but I think that's permitted at that point, its still just a dictioanry.# | 09:00.32 |
| | It just stores the font at that time | 09:00.50 |
| | It then defines the FOntDescriptor simlarly | 09:01.07 |
| chrisl | Right, so then we get the encoding, then the font descriptor, then the font file stream | 09:01.17 |
| kens | Yes | 09:01.23 |
| chrisl | And we eventually define the font after we get the file stream | 09:01.44 |
| kens | When it finishes the font stream it creates the font | 09:01.44 |
| chrisl | Right: how does it know that the stream is for a font? | 09:02.02 |
| kens | I think its the TypeDameons again | 09:02.26 |
| | OK BEcause its a FontFile object | 09:02.42 |
| | Not sure how it know that, maybe it searches | 09:03.11 |
| chrisl | No, it's a stream object, that is referenced by the name FontFile2 | 09:03.15 |
| kens | Yes but it knows its a fontfile when it executes the stream I mean | 09:03.33 |
| chrisl | When we get to endobj for the stream, the stream dictionary contains a /.endobj_daemon entry | 09:04.10 |
| kens | It knows before it gets there, it knows at the beginning of the satream | 09:04.26 |
| | Look at line 591, '/stream' | 09:04.36 |
| chrisl | GetObject? | 09:05.27 |
| kens | When it starts the stream it says 'Executing the FontFileDaemon for 20' | 09:05.37 |
| | Let me see how it determines that | 09:05.48 |
| | Ah, I think it may be that the FontDescriptor object leaves a FontFileDaemon on the stack | 09:06.52 |
| | Expecting that the next object will bethe FOntFile stream | 09:07.04 |
| | Because we control the creation of the file we can guarantee that is the case | 09:07.34 |
| chrisl | Stack is empty after the font descriptor endobj | 09:08.25 |
| kens | Hmm, well it definitely creates an executable array before it finishes | 09:08.49 |
| | Oh, its calling //Register | 09:09.22 |
| | look around line 868 | 09:09.32 |
| | part of /FontDescriptor | 09:09.42 |
| | It creates an executable array and then calls //Register with it | 09:09.58 |
| | Oops,I've broken my copy of the file, could you send it again please ? | 09:11.47 |
| chrisl | On its way | 09:12.50 |
| kens | THanks, I'll make a copy this time.... | 09:13.05 |
| | I think /Re | 09:13.29 |
| | sorry | 09:13.34 |
| | I think /Regsiter uses PutObject to connect the object number with the Daemon, then when it encoutners the stream it nkows to run that Daemon with that object number | 09:14.11 |
| chrisl | Yes, I'm beginning to see a vague outline of what's going on - this simply cannot be the best way to make this work :-( | 09:15.02 |
| kens | I couldn't possibly comment....... | 09:15.22 |
| | I've not ahad to deal with this stuff much, it usually 'just works' | 09:15.44 |
| chrisl | Okay so, two things FYI: the guy with the crashing printer was mistaken - the 9.05 output crashes, too. What he thought was 9.05 output was actually the poppler output.... | 09:16.20 |
| kens | :-) | 09:16.41 |
| chrisl | (hence why I'm trying to get some handle on this to instrument the PS in some way) | 09:16.45 |
| kens | THat at least doesn't surprise me | 09:16.51 |
| chrisl | Second, the 9.07/HEAD code's output from the PDF errors out when running with -dPDFR_DEBUG | 09:17.38 |
| kens | I see that when I run /streamfor the FontFile GetObject returns an object which we execute | 09:17.47 |
| | chrisl on the printer ? | 09:17.58 |
| chrisl | No, in GS | 09:18.15 |
| kens | Not for me | 09:18.19 |
| | At least it didn't until I edited the file, now it does... | 09:18.32 |
| chrisl | That's 9.05's output you're using | 09:18.41 |
| kens | (Maybe I'm making that up, let me retry) | 09:18.48 |
| | Oh, should read the code... | 09:18.59 |
| chrisl | If you grab the "Original PDF" from http://bugs.ghostscript.com/show_bug.cgi?id=693652 | 09:19.10 |
| kens | THe 9.05 output errors with PDFR_DEBUG true as well | 09:20.14 |
| chrisl | Run it through ps2write, then run the resulting PDF with -dPDFR_DEBUG, it errors with a rangecheck; OffendingCommand: getinterval | 09:20.19 |
| kens | Seems to be common to both | 09:20.44 |
| chrisl | Hmm, the 9.05 output works okay for me, I think.... hang on | 09:20.57 |
| kens | Not for me, that was what had me going, I thought it was because I'd edited the file, in fact its the PDFR_DEBUG that does it | 09:21.20 |
| | Hmm, funny stuff on the stack,it looks like its breaking the TrueType loading | 09:22.12 |
| chrisl | Hmm, I'm running it with 9.05 as well, I wonder if that makes a difference..... | 09:22.41 |
| kens | Its hard to see why, let me try 9.05 with the file | 09:22.59 |
| | Bizarrely that does indeed work | 09:23.57 |
| chrisl | Okay, good, at least we're consistent! I'll maybe bisect it later on | 09:24.22 |
| kens | Its a problem intriduced later it seems. | 09:24.23 |
| | But the 9.07 output fails even with 9.05 ? | 09:24.45 |
| | (with PDFR_DEBUG) | 09:24.53 |
| chrisl | Not sure..... | 09:24.59 |
| kens | I'll try it | 09:25.13 |
| chrisl | The 9.06 output is okay, so it is something on the interpreter side. | 09:25.42 |
| kens | Very strange | 09:25.59 |
| | The original file, converted to PS with 9.07 then the PS run through 9.05 with PDFR_DEBUG is OK here too | 09:26.52 |
| | Well it seems to fail trying to read the second short for one fo the encodings. | 09:28.55 |
| | Anyway, this isn't really the original problem | 09:29.07 |
| chrisl | Could be 64 bit integers causing the problem | 09:29.14 |
| kens | I was wondering if we'd changed the size of something yes | 09:29.25 |
| | THe working setup goes | 09:29.58 |
| | NumEncodings = 2 | 09:29.58 |
| | 00030000 [282 318 null] | 09:29.58 |
| | The failing one goes | 09:30.11 |
| | NumEncopdings = 2 | 09:30.11 |
| | 0003 | 09:30.11 |
| | WOuld have to debug further to find out what's dying there, but I'm not sure its worth it right now. | 09:30.38 |
| | Can I help further with the real problem ? | 09:30.51 |
| chrisl | No, thanks, I'm just to stick some showpages in a strategic points, and try to narrow down where the printer is actually failing | 09:31.24 |
| kens | OK then I'll go back to trying to constrcut a working type 3 image. | 09:31.43 |
| chrisl | That's probably more interesting...... | 09:31.56 |
| kens | Its part of my colour space testing, I can't see why I'm getting a rangecheck, clearly I have something wrong.... | 09:32.30 |
| kens | returns to the PLRM | 09:32.49 |
| chrisl | or there's a bug - it's not a very common image type | 09:32.53 |
| kens | Yeah but my usage is so simple-minded I can't believe its that | 09:33.16 |
| | I've just done somethgin wrong is all | 09:33.25 |
| Robin_Watts | kens/chris: About the contrib thing. | 10:22.35 |
| | I was initially in favour of leaving contrib where it was. | 10:22.47 |
| | but ray points out that it'd still be a single directory with all the contrib things in. | 10:23.13 |
| | I can see that there would be an argument for keeping the contrib stuff in a separate dir in the top level, but it's already not at the top level. | 10:23.48 |
| kens | I don't feel strongly about it, but I think putting it outside devices makes it clearer its not 'our' code. | 10:23.48 |
| Robin_Watts | (It's 'gs/contrib', not 'contrib') | 10:24.02 |
| kens | Robin_Watts : it is for 'Ghostscript' | 10:24.08 |
| | Well, everything is under gs | 10:24.20 |
| Robin_Watts | kens: No, not everything is under gs. | 10:24.38 |
| kens | True, It used to be though | 10:24.56 |
| | This re-organisation has happened at least once before, and stopped part way | 10:25.13 |
| Robin_Watts | I do wonder if in this great reorg, we should remove the GhostPDL/Gs distunction. | 10:25.18 |
| kens | Personally I would be in favour | 10:25.31 |
| | That's where we stopped last time | 10:25.38 |
| Robin_Watts | and just have psi as another language at the same level as pcl or xps or... | 10:25.48 |
| kens | psi is at the same level already | 10:26.33 |
| | "/ghostpdl/psi" | 10:26.54 |
| | But its not the real one | 10:27.09 |
| Robin_Watts | Right. | 10:27.18 |
| | So gs/base could become just 'lib' maybe, and gs/devices would become devices etc. | 10:27.47 |
| kens | I'd be happier with that myself | 10:27.59 |
| | But its a nightmare for the build I think, everything has to change | 10:28.10 |
| | WHich (I think) is why its not happened before | 10:28.22 |
| | We'd probably need a '3rd party' library to store things like openjpeg zlib etc in a neat fashion, otherwise the top level directory would be unbearably cluttered | 10:29.28 |
| | Topic for the staff meeting ? | 10:29.50 |
| Robin_Watts | Sounds a lot like it to me. | 10:30.35 |
| | a libs dir ? As some of the libs (jbig2dec) are actually ours. | 10:31.22 |
| | libs rather than thirdparty | 10:31.32 |
| kens | I don't really mind what its called, just an observation that moving all the dependencies from ghostpdl to the top level would be a mess | 10:31.57 |
| | OK type 3 images working now..... | 10:33.59 |
| chrisl | Robin_Watts: that would make it pain doing the release - there'd would be a lot more faffing about to get the Ghostscript distribution | 10:52.11 |
| Robin_Watts | chrisl: You'd take a subset of dirs, rather than a single one, but yes, I see your point. | 10:54.23 |
| chrisl | Yeh, then there would be the configure script(s) and makefile(s) to sort out so each distribution got something that worked..... | 10:57.40 |
| Robin_Watts | tor8: ping! | 11:56.44 |
| | tor8: 3 reviews on robin/master for you. | 11:58.39 |
| Robin_Watts | disappears for a bit to fit new SSD and Harddrive. | 11:58.55 |
| robin_watts_mac | tor8:ping | 12:53.04 |
| | I wish gparted gave some indication of how far a job it was :( | 13:05.54 |
| | s/far/far through/ | 13:06.11 |
| tor8 | robin_watts_mac: pong. | 13:27.19 |
| sebras | robin_watts_mac: LVM..? ;) | 14:00.18 |
| henrys | chrisl:usually when did you put mupdf 1.2 on ghostscript downloads? I didn't see an email to everyone did I miss it. | 14:09.57 |
| | ? | 14:10.01 |
| chrisl | henrys: Sorry, I didn't send out an e-mail - I put it up just after tor8 released it | 14:10.39 |
| henrys | chrisl:okay np, we do need a better way to broadcast the mupdf release so the entire staff knows (like ghostscript), maybe tor8 should send a message to everybody, I don't know. | 14:16.37 |
| chrisl | henrys: tbh, I thought tor8 or robin_watts_mac did it. I'm happy to send notification out once I've done the commercial release and the downloads page | 14:17.42 |
| robin_watts_mac | sebras: What's LVM ? | 14:20.40 |
| | Damn. Copied old SSD to new one, and new one won't boot :( | 14:21.11 |
| henrys | chrisl, tor8: I don't know maybe you and tor8 can decide how to do it, but we should have something to staff@artifex.com when the commercial release is available. | 14:21.29 |
| robin_watts_mac | tor8: sorry, was at lunch. | 14:21.52 |
| chrisl | robin_watts_mac: I assume from the context "Logical Volume Management" | 14:21.58 |
| sebras | robin_watts_mac: logical volume management. | 14:22.06 |
| robin_watts_mac | ok. so my next question: logical volume mangement? | 14:22.26 |
| | I have a 128Gig SSD that I boot of off, and it's full. | 14:22.47 |
| sebras | robin_watts_mac: but I see now that you are not _just_ adding more volumes, but actually moving your main OS partitions to a presumably faster SSD. | 14:22.49 |
| robin_watts_mac | Y | 14:22.56 |
| chrisl | henrys: I'll fit in with whatever tor8 prefers | 14:22.58 |
| henrys | thanks | 14:23.13 |
| robin_watts_mac | I've just bought a new 250Gig SSD, and I'd like to move the contents of the 128Gig one onto that, and boot from it. | 14:23.26 |
| sebras | robin_watts_mac: LVM basically allows you to add/remove/resize volumes easy. | 14:23.32 |
| robin_watts_mac | LVM is part of what ? | 14:23.42 |
| | linux or windows? | 14:23.46 |
| sebras | robin_watts_mac: linux. :) | 14:23.59 |
| robin_watts_mac | I use a gparted live CD for such things normally. | 14:24.08 |
| | Let me retry, with more care with sector numbers etc. | 14:24.35 |
| henrys | robin_watts_mac:mac os x? | 14:28.18 |
| robin_watts_mac | windows | 14:28.28 |
| | for macos x I used carbon copy cloner | 14:28.39 |
| henrys | I had read there was some voodoo in 10.7 that really required you to reinstall the os. but I guess you've proven that wrong ! | 14:29.52 |
| robin_watts_mac | ccc worked well when i went from 250gig hd to 750gig hybrid | 14:30.33 |
| henrys | alexcher:I'll take care of the bounty question if you haven't done so already. | 14:34.45 |
| pancho_jay | hi! | 14:36.42 |
| | chrisl, ping! | 14:36.51 |
| chrisl | pancho_jay: pong | 14:37.04 |
| pancho_jay | how are you? | 14:37.09 |
| ghostbot | just great, pancho_jay | 14:37.09 |
| chrisl | Looking forward to the weekend ;-) | 14:37.28 |
| pancho_jay | chrisl, TGIF :) | 14:37.37 |
| | yesterday I came here looking for help with ghostscript | 14:38.04 |
| chrisl | It's good place for that..... | 14:38.34 |
| pancho_jay | and tolk with mvrhel_laptop, he said that maybe you can help me | 14:38.37 |
| chrisl | Oh, about pdfwrite? You'd better with kens tbh | 14:39.12 |
| pancho_jay | I was trying to concatenate some pdf files into a big one, but some characters were changed or dissapear! | 14:40.03 |
| chrisl | pancho_jay: however, I suspect the problem you're having is incompatible font subsets with the same name(s) | 14:40.13 |
| pancho_jay | chrisl, nice... so what can I do? | 14:40.30 |
| | (sorry about my english, I am from Argentina! If you speak spanish.....) | 14:40.52 |
| chrisl | I don't, I'm afraid..... | 14:41.23 |
| | pancho_jay: anyway, did you try Ghostscript 9.07? | 14:41.35 |
| pancho_jay | nope, I didn't | 14:41.51 |
| kens | pancho_jay, get trhe fonts correct in the first place. A work around is to use ps2write to first convert to POstScript then run the PostScript through pdfwrite to get a PDF | 14:41.52 |
| chrisl | kens: won't the new hashing code resolve this? | 14:42.33 |
| pancho_jay | I am generating original PDFs with libreoffice | 14:42.46 |
| kens | chrisl yes, but only by first converting to PS | 14:42.49 |
| | chrisl so that the font names are correct | 14:43.06 |
| chrisl | Oh, so the fresh subset prefix generation only come in for ps2write? | 14:43.28 |
| kens | No.... | 14:43.49 |
| chrisl | Okay, confused..... | 14:44.33 |
| kens | Its complicated. | 14:45.21 |
| chrisl | :-) | 14:45.31 |
| kens | ps2write works not quite the same as pdfwrite here | 14:45.32 |
| | SO we get all the same fonts but properly named | 14:45.45 |
| | (no compaction) | 14:45.53 |
| chrisl | So pdfwrite tries to merge subsets, but ps2write doesn't? | 14:46.43 |
| pancho_jay | mmmm | 14:47.11 |
| | great problem for me | 14:47.17 |
| | I think that maybe I can use cups or something similar to avoid that issue... | 14:47.41 |
| henrys | robin_watts_mac: was the ssd significant on your mac? | 14:51.21 |
| pancho_jay | or try ps2write instead | 14:51.23 |
| robin_watts_mac | henrys: I have much more free space. | 14:51.36 |
| chrisl | pancho_jay: the problem is that font names should be unique, so when an application generates a PDF with a subset font in it, it needs to add a "random" prefix to the font name so the name for that specific subset is unique | 14:51.42 |
| robin_watts_mac | I have no (noticable) change in battery life | 14:51.53 |
| | And I forgot to do 'before' timings for builds. | 14:52.05 |
| | I think they are faster. | 14:52.17 |
| pancho_jay | chrisl, ok... i see! | 14:52.25 |
| robin_watts_mac | I didn't buy the drive for a massive speed boost, more a massive space boost :) | 14:53.05 |
| pancho_jay | chrisl, so if I have 2 pdfs with the same font, that fonts are renamed and then files are merged? | 14:53.16 |
| henrys | it is hyped as being a great speed performance upgrade. | 14:53.17 |
| chrisl | pancho_jay: renaming the fonts (correctly!) would work, but it's not as simple as it sounds | 14:53.55 |
| henrys | robin_watts_mac most people are upgrading to ssd's and lose space. | 14:54.28 |
| robin_watts_mac | SSD are a great speed improvement. | 14:54.46 |
| | hybrid ones... less so. | 14:54.54 |
| chrisl | pancho_jay: pre-processing with ps2write will rename the fonts "correctly" for you, but there may be other issues with that conversion route | 14:55.25 |
| robin_watts_mac | but it depends on your usage. If you are compute or memory bound, then an SSD ain't gonna help. | 14:55.38 |
| pancho_jay | chrisl, I can understand why renaming fonts is to complex??? why you can generate a unique prefix for each one? | 14:57.11 |
| kens | pancho_jay : pdfwrite assumes two fonts with teh same name are the same font | 14:57.50 |
| | THe 'random' prefix on subset fonts is top prevent that happening | 14:58.08 |
| | If the prefix is not unique then pdfwrite ends up trying to treat the two different fonts as the same font. | 14:58.54 |
| | ps2write is less sophisticated than pdfwrite in this case, and so doesn't get confused. As a bonus, when subsetting fonts itself it uses a technique to generate the prefix which is almost guaranteed to produce unique prefixes. | 14:59.44 |
| | So as long as you let it generate the subset, it 'fixes' the problem | 14:59.58 |
| | Sending the PostScrip twith the fixed font names topdfwrite gets a valid, correct, PDF | 15:00.27 |
| pancho_jay | kens, thanks! | 15:01.05 |
| | brb!! | 15:01.10 |
| kens | As too why we cna't generate a unique prefix for each font, we can, that's not the problem. The problem is that your PDF files *don't* have unique prefixes | 15:01.11 |
| robin_watts_mac | tor8:ping | 15:12.30 |
| tor8 | robin_watts_mac: ping. | 15:12.44 |
| robin_watts_mac | aha. | 15:12.49 |
| | First off there are 3 commits for you to review. | 15:12.58 |
| | secondly, did you see zenikos comments about passwords? | 15:13.10 |
| tor8 | fz_fopen I'm not too fond of. there must be a better way to #ifdef the windows specific cruft. | 15:13.17 |
| robin_watts_mac | (spun off into bug 693425) | 15:13.26 |
| | tor8: I'm open to suggestions | 15:13.42 |
| tor8 | outlines I have no opinion on, but it looks reasonable. | 15:14.19 |
| robin_watts_mac | We need to do do allocation to do the utf8->ucs conversion, therefore we need a context | 15:14.40 |
| tor8 | softmask, I'm going to have to trust you on, my transparency knowledge is paged out on tape by now :) | 15:14.46 |
| | robin_watts_mac: the password stuff I don't understand | 15:15.08 |
| robin_watts_mac | (or else we have to use free/malloc, which might not be the end of the world) | 15:15.18 |
| | The password stuff... the authentication routines currently assume they get a set of byte values in, and use them directly. | 15:16.59 |
| | but with mudraw on windows now running in a unicode world, we get unicode in, which we convert to utf8. This means that the password ends up being recorded in utf8. | 15:18.12 |
| | Similarly on linux, we'll have the password in utf8 too. | 15:18.23 |
| tor8 | robin_watts_mac: hmm. do the newer versions of the pdf spec state which encoding passwords are in? | 15:19.05 |
| | from past experience, they've been "local codepage of the creator, with no way to know which" | 15:19.25 |
| robin_watts_mac | My commit there converts the utf8 down to bytes which effectively puts us back where we've always been. | 15:19.25 |
| | See bug 693425. | 15:19.34 |
| | According to zeniko Adobe has documented what encodings the passwords are in. | 15:19.49 |
| tor8 | that's the scrolling bug | 15:20.00 |
| robin_watts_mac | http://bugs.ghostscript.com/show_bug.cgi?id=693675 | 15:20.47 |
| | sorry | 15:20.49 |
| tor8 | reading the bug comments now | 15:20.56 |
| robin_watts_mac | so arguably we should always be passing the password in as utf8 and letting authenticate do any encoding fiddling that's required. | 15:21.26 |
| tor8 | right. so the pdf_authenticate_password should take a utf-8 in, and convert that to pdf-doc-encoding depending on encryption version | 15:22.09 |
| robin_watts_mac | right. | 15:22.17 |
| | so, that acn | 15:23.00 |
| | bah. | 15:23.03 |
| tor8 | #ifdef win32 #define fopen fz_fopen #endif ? | 15:23.12 |
| robin_watts_mac | so that can sit there until one of us feels like it | 15:23.22 |
| tor8 | and #undef fopen at the top of the file that defines it | 15:23.24 |
| robin_watts_mac | tor8: and use malloc/free ? | 15:23.39 |
| tor8 | we can probably get away with using microsofts own MB conversion functions on windows | 15:24.12 |
| | but yes, just use malloc/free (or PATH_MAX) | 15:24.27 |
| robin_watts_mac | tor8: we still need a buffer. | 15:24.51 |
| | and PATH_MAX is asking for trouble, | 15:25.00 |
| tsbtmn | With mupdf 1.2, I am finding that the new behaviour of mouse scrolling is quite slow when viewing a document at a high DPI. This is getting in the way of my workflow. Can the mouse scrolling behaviour be toggled to the old style? | 15:31.09 |
| Robin_Watts | henrys: http://www.tomshardware.com/reviews/momentus-xt-750gb-review,3223-8.html | 15:47.37 |
| henrys | Robin_Watts: yes all sorts of clues from the universe that a retina mac is in my future. | 15:49.26 |
| tsbtmn | tor8: Slow mouse scrolling seems particularly bad at high DPI's. | 15:51.22 |
| | tor8: Looking at it a bit more closely I think it's not just the scrolling. I also just noticed that it is slow to draw a selection area when right-clicking and dragging. | 15:54.06 |
| tor8 | tsbtmn: none of that should have changed since last release, though. | 15:57.04 |
| | the only thing that may have changed is which VS version was used to compile | 15:57.21 |
| | is there a noticeable difference from the 1.1 release? | 15:58.04 |
| tsbtmn | tor8: I have been switching back and forth between 1.1 and 1.2 for comparison and I am seeing a big difference between the two. | 16:02.04 |
| Ben___ | Hi. I submitted a bug report and was told problem was already fixed, but I needed latest HEAD | 16:10.08 |
| | I downloaded the HEAD, but not sure how to build it to what I'm familiar with. Can someone help me? | 16:10.26 |
| kens | What OS are you using ? | 16:10.34 |
| Ben___ | Win7 | 16:10.37 |
| | 64-bit | 16:10.41 |
| | I have vis studio if needed | 16:10.53 |
| kens | THen you need Visual Studio, open the supplied solution and build | 16:11.00 |
| Ben___ | does it matter which version of Visual studio I use? | 16:11.25 |
| | when I try opening with vs 2012 it asks me to upgrade | 16:12.10 |
| kens | It works with 2005, 2008 and 2010 other versions your mileage may vary | 16:12.10 |
| Robin_Watts | Ben___: Hi. Any VS version > 2005 will tell you it needs to upgrade the project. That's fine, just let it do what it wants. | 16:12.50 |
| | We provide the solution in VS2005 so it can work for everyone (albeit with this upgrade step) | 16:13.08 |
| | If we provided it in VS2012, then everyone with lower versions would be stuffed. | 16:13.27 |
| chrisl | There will be warnings, but should be no errors if the project upgrades | 16:13.39 |
| Robin_Watts | tor8: Updated commit: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=fa469bd085112c5ba242b03bd696c1ee2bd60404 | 16:17.05 |
| tor8 | Robin_Watts: drop the auth_password_utf8 and it's okay | 16:23.25 |
| | fo = (fopen)(argv[1], "wb"); I don't understand | 16:23.50 |
| | why the extra parens? | 16:23.55 |
| Robin_Watts | (fopen) doesn't match fopen(a,b) | 16:24.08 |
| tor8 | #undef fopen on the line above would be clearer | 16:24.24 |
| Robin_Watts | otherwise I need to implement fopen_utf8 in cmapdump. | 16:24.25 |
| tor8 | but right | 16:24.38 |
| | didn't notice which file it was in | 16:24.50 |
| Robin_Watts | If I drop the auth_password_utf8, then no passwords would work that have top bits set, right? | 16:25.05 |
| | I think we should leave auth_password_utf8 in until such time as we change the authentication stuff to do the encoding mapping internally. | 16:25.37 |
| | This way, we behave exactly as we always have before. | 16:25.46 |
| tor8 | Robin_Watts: well, considering we couldn't open passwords with top bits set before either (since we don't pdfdocencode them) I don't see the need | 16:29.47 |
| | it should be a separate patch at least | 16:29.56 |
| Robin_Watts | tor8: we could. | 16:30.08 |
| | Previously we did: mudraw -p BLAH -o out.png in.pdf | 16:30.26 |
| tor8 | I'm happy to code up the utf-8 to pdfdocenc stuff | 16:30.30 |
| Robin_Watts | On windows BLAH would be taken as a literal set of bytes, and passed through. | 16:30.50 |
| tor8 | does docenc have common bits with latin-1? | 16:30.57 |
| Robin_Watts | On linux those bytes would have been utf8 encoded, and hence wouldn't have worked. | 16:31.38 |
| | With the new code, on windows, we get BLAH in as unicode, convert to utf8 and back, and it works. | 16:32.13 |
| | With the new code on linux, we get BLAH in utf8, and we convert them back to utf8 and it works. | 16:32.33 |
| | The only times it doesn't work is when the user is expecting to give us encoded bytes rather than raw ones. | 16:33.17 |
| | I have no idea about docenc at all :( | 16:33.41 |
| | So, if I split out into 2 separate patches (utf8 filenames in one, utf8 passwords in another). you'd be happy? | 16:34.29 |
| | Then you can do the 'proper' solution at your leisure? | 16:34.42 |
| | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=6379e1c56de3d38741c7d36effc5d43aeafe59d3 | 16:47.45 |
| | and: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=9da3120d69035f95014aaae0d6420e0609173259 | 16:47.55 |
| Ben___ | when I build, I get a debugbin that contains gswin32c.exe. Should I be able to use that for what I need (txtwrite)? | 16:48.27 |
| tor8 | maybe note that it's windows specific in the commit message | 16:48.27 |
| Ben___ | (because when I try that, it crashes) | 16:48.56 |
| tor8 | Robin_Watts: the windows app also calls password functions from the gui | 16:49.10 |
| Robin_Watts | right, but we haven't converted those to utf8. | 16:49.36 |
| | they are raw bytes. | 16:49.42 |
| kens | Ben___ : you should also get gswin32.exe, and yes it should work | 16:49.45 |
| Ben___ | I'll try without the c | 16:49.58 |
| tor8 | Robin_Watts: right. should fix that too in the "real" fix. | 16:50.00 |
| Ben___ | still crashes: "gswin32.exe has stopped working | 16:50.28 |
| Robin_Watts | tor8: "Ensure that windows copes with utf8 filenames" | 16:50.29 |
| Ben___ | " | 16:50.29 |
| tor8 | Robin_Watts: yes :) | 16:50.51 |
| kens | just start it with no arguments and see what happens | 16:51.00 |
| Ben___ | starts fine | 16:51.17 |
| kens | Hmm what is the SHA of your git checkout ? | 16:51.36 |
| Robin_Watts | tor8: Updated to be more windowsy :) | 16:51.37 |
| Ben___ | how do I find that? | 16:52.15 |
| Robin_Watts | git log -1 | 16:52.22 |
| kens | what robin said | 16:52.30 |
| Robin_Watts | What's the top line: commit fdsflkshflkjfhsldjh# | 16:52.38 |
| Ben___ | not well versed in git. Had to have someone help me use it to get the HEAD | 16:53.34 |
| | I opened Git Bash and typed 'git log -1' | 16:53.43 |
| | fatal: Not a git repository | 16:53.49 |
| kens | not good | 16:54.01 |
| Robin_Watts | cd path/to/your/checkout | 16:54.06 |
| | For instance, for me, it's cd /d/cvs/artifex/ghostpdl.git/ | 16:54.37 |
| | cos I'm on drive d. | 16:54.46 |
| Ben___ | mine's just C:\gs\ | 16:55.02 |
| | but it's giving me the same error from that dir | 16:55.08 |
| kens | so cd /c/gs | 16:55.13 |
| Robin_Watts | Then you haven't got a git checkout, so I'm confused. What did you do to get your copy of gs ? | 16:55.50 |
| ray_laptop | kens: were you investigating doing a port monitor ? | 16:55.59 |
| kens | ray_laptop : no not really | 16:56.15 |
| Ben___ | I remember we tried svn also ... maybe that's what we ended up doing. But I thought we got it through git | 16:56.31 |
| Robin_Watts | Woooah. SVN is WAY old. That won't work. | 16:56.46 |
| kens | Best to use Git | 16:56.46 |
| Ben___ | ok | 16:56.55 |
| kens | You are going to need a Git checkout of the current HEAD | 16:57.14 |
| Ben___ | is there a good tutorial for how to do that? | 16:57.16 |
| Robin_Watts | so inside C:\gs, do you have a debugbin directory ? | 16:57.20 |
| Ben___ | yes | 16:57.31 |
| Robin_Watts | OK, then I can say with confidence that that did not come from git. | 16:57.41 |
| Ben___ | ok | 16:57.46 |
| Robin_Watts | So... in git bash do the following. | 16:58.02 |
| | cd /c/ | 16:58.05 |
| kens | Ben___ : what does GS sy when you start it up ? | 16:58.23 |
| Ben___ | ahhh ... SVN PRERELEASE 9.03 from 3/30/2011 | 16:58.46 |
| | :) my bad | 16:58.49 |
| | no wonder txtwrite doesn't exist there | 16:58.58 |
| | (following your instructions, Robin) | 16:59.09 |
| kens | OK as Robin ays, not Git checkout, you need the Git checkout | 16:59.10 |
| Robin_Watts | git clone http://git.ghostscript.com/ghostpdl.git | 16:59.37 |
| | That should make you a C:/ghostpdl.git directory. In there there will be the gs directory that you are familiar with. | 17:00.12 |
| Ben___ | cloning into ghostpdl | 17:00.14 |
| | ok, done checking out files. So now I just need to build the project and I can use the resulting gswin32.exe, right? | 17:03.17 |
| Robin_Watts | right. | 17:03.24 |
| Ben___ | thanks so much for walking me through it. I appreciate it. | 17:03.47 |
| Robin_Watts | no worries. | 17:04.22 |
| Ben___ | now I'm getting "Error: /undefined in -sDEVICE=txtwrite" | 17:16.46 |
| Robin_Watts | Ben___: Can you give us your exact command line please ? | 17:17.16 |
| Ben___ | -sDEVICE=txtwrite -o=C:\testingagain.txt C:\Temp\SouthernTesting\3620644.PDF | 17:18.01 |
| kens | -o= won't work | 17:18.16 |
| Robin_Watts | -o C:\testingagain.txt | 17:18.36 |
| Ben___ | same thing when I do -OutputFile= | 17:18.40 |
| | oh | 17:18.45 |
| kens | -sOutputFile | 17:18.46 |
| Robin_Watts | Not -o=C:\testingagain.txt | 17:18.47 |
| Ben___ | still undefined in txtwrite though | 17:19.22 |
| | I got it working | 17:20.52 |
| | did it through Windows CMD this time instead of opening ghostcript first | 17:21.08 |
| Robin_Watts | Ben__: Oh, you were trying to type that into the console window? | 17:22.30 |
| | The console window expects postscript input. What you have there are command line arguments, NOT postscript, so that would have failed, yes. | 17:23.04 |
| Ben___ | :) thanks again for the help | 17:24.20 |
| Robin_Watts | np. | 17:24.25 |
| | Morning mvrhel_laptop. Did you get mupdf working again? | 18:08.10 |
| mvrhel_laptop | Robin_Watts: fighting with it right this second. I should be able to work through this | 18:08.38 |
| | It is good that I am going to a different solution file | 18:09.00 |
| | but somehow mine got mucked up | 18:09.21 |
| Robin_Watts | It sounds like the sanest solution (no pun intended) | 18:09.21 |
| mvrhel_laptop | :) | 18:09.30 |
| | oh I see the issue | 18:10.06 |
| ray_laptop | FINALLY. The file Bug690395.pdf was one of the ones that showed a bmpcmp difference, but at 300 dpi it broke all of the visual comparison tools. And Photoshop SUCKS (I see the difference in the file, but differencing the layers doesn't show it) :-( | 18:10.21 |
| Robin_Watts | ray_laptop: What format file ? | 18:10.41 |
| malc_ | robin_watts_mac: hi, did the code help? | 18:10.42 |
| ray_laptop | FINALLY I got it to bomb at 200 dpi during clist rendering with a bad op | 18:10.46 |
| | Robin_Watts: plank | 18:10.54 |
| Robin_Watts | malc_ sorry, I haven't had a chance to look yet. | 18:10.58 |
| | ray_laptop: You can use my image viewer! :) | 18:11.07 |
| ray_laptop | Robin_Watts: where is it ? | 18:11.23 |
| Robin_Watts | http://ghostscript.com/~robin/ipview.html | 18:12.03 |
| ray_laptop | Robin_Watts: I wrote a quicky pam2ppm so that at least Photoshop can open it (and my tools can, if the file is small enough) | 18:12.31 |
| | the diffference is there in the ppm file, but Photoshop doesn't show it | 18:13.01 |
| mvrhel_laptop | Robin_Watts: where is pdf_new_pdf_device defined? | 18:13.02 |
| Robin_Watts | My thing is a simple javascript app that draws pams or pngs to a canvas, and you can enable/disable layers. | 18:13.20 |
| | mvrhel_laptop: That's a new file. Let me find it. | 18:13.28 |
| mvrhel_laptop | ah | 18:13.32 |
| Robin_Watts | pdf/pdf_device.c | 18:13.45 |
| mvrhel_laptop | this will be the disadvantage of having a separate solution... | 18:13.59 |
| Robin_Watts | ray_laptop: Let me know if it works for you. | 18:14.02 |
| | mvrhel_laptop: yeah... | 18:14.07 |
| mvrhel_laptop | but that is an easy fix | 18:14.14 |
| | compared to the headaches the other approach would be | 18:14.33 |
| | thanks | 18:14.37 |
| ray_laptop | Robin_Watts: It just shows me a Browse... prompt, I get a pop up file open dialog, select the PAM, then click 'Open' in the file dialog and it goes back to the screen now with the path filled in, but then it just sits there | 18:16.13 |
| Robin_Watts | ray_laptop: Can you give me a copy of your file please? | 18:16.35 |
| | What browser? | 18:16.41 |
| ray_laptop | Robin_Watts: I am using firefox | 18:16.44 |
| | version 18.0.2 | 18:16.59 |
| | Robin_Watts: I'll try with chrome... | 18:17.12 |
| Robin_Watts | Works for me in my firefox. | 18:17.25 |
| | 16.0.2 admittedly. | 18:17.46 |
| ray_laptop | Robin_Watts: w/ chrome I get the "Aw, Snap!" display | 18:18.49 |
| Robin_Watts | And again in 19.0 | 18:18.53 |
| | ray_laptop: How big is the file? | 18:19.02 |
| | I'm testing with a 1600x1600 one here. | 18:19.11 |
| ray_laptop | Robin_Watts: my PAM is W 15748 H 4860 | 18:19.48 |
| Robin_Watts | That may be the issue. can I get a copy of it please? | 18:20.10 |
| ray_laptop | Robin_Watts: and that's the lower res, cut down file | 18:20.11 |
| mvrhel_laptop | looks like stm_output.c is new too | 18:20.26 |
| Robin_Watts | mvrhel_laptop: Yes, probably, sorry. | 18:20.43 |
| mvrhel_laptop | Robin_Wattsno worry | 18:20.50 |
| ray_laptop | gswin32c -r200 -g15748x4860 -sDEVICE=plank -dBandHeight=135 -o ref.pam -Z: c:/Artifex/tests_private/comparefiles/Bug690395.pdf | 18:20.51 |
| mvrhel_laptop | it was easy to find | 18:20.54 |
| | ok now I am up and running again | 18:21.12 |
| | need to head out for bit | 18:21.34 |
| | bbiaw | 18:21.36 |
| ray_laptop | Robin_Watts: but, like I said, with my changed version, I'm able to get an Unrecoverable clist error (bad op) | 18:21.37 |
| kens | goddnight all | 18:22.26 |
| Robin_Watts | Night kens | 18:22.39 |
| ray_laptop | Robin_Watts: so I have something to work on. | 18:23.23 |
| Robin_Watts | ray_laptop: Yeah, the browser runs into memory problems with that file :( | 18:24.54 |
| | Not much I can do about that really. | 18:25.13 |
| ray_laptop | Robin_Watts: same problem I was having with my other tools. :-( | 18:25.55 |
| | which is why I started lowering the res and chopping the page size down to try and get something I could see, when I tripped over the 'bad op' | 18:26.36 |
| | The thing is that this is _supposed_ to be my pdf14 clist optimization changes, and the file DOESN'T have transparency :-/ | 18:27.41 |
| Robin_Watts | ah :( | 18:29.43 |
| ray_laptop | oh, great! I rebuilt and now it doesn't fail | 18:31.43 |
| | oops. wrong source branch. | 18:32.00 |
| | at least I'm able to debug the bad op case now | 18:57.55 |
| | this is probably something that's been laying around for a while. | 18:58.32 |
| | oops. One of the things I broke was -ZL :-( Fix that first... | 19:08.41 |
| Robin_Watts | ok, I'm going to reboot so I can copy 1.2TB of data between harddrives without windows having a paddy about open files. | 19:55.35 |
| | Have a good weekend all! | 19:55.39 |
| mvrhel_laptop | robin_watts_mac: you still around? | 21:46.24 |
| malc_ | robin_watts_mac: profile is dominated by hash | 21:52.04 |
| | according to both callgrind and perf.. | 21:52.30 |
| mvrhel_laptop | robin_watts_mac: ok. successfully pushed my winRT branch to my local repo. now I am going to do a clean checkout to see it I got everything in there | 21:53.46 |
| | ok. missing a few things.... | 21:59.19 |
| | ok. now it all seems to be in place | 22:30.06 |
| | now to do some real work again... | 22:34.54 |
| sebras | make -j10 build=release | 22:51.00 |
| | Package libopenjpeg was not found in the pkg-config search path. | 22:51.00 |
| | Perhaps you should add the directory containing `libopenjpeg.pc' | 22:51.01 |
| | to the PKG_CONFIG_PATH environment variable | 22:51.01 |
| | No package 'libopenjpeg' found CC build/release/base_context.o | 22:51.01 |
| | say what!? since when does mupdf depend on pkg-config..? | 22:51.14 |
| malc_ | since the world went multicore i suppose | 22:52.52 |
| sebras | malc_: ehm..? | 22:53.46 |
| | malc_: but mupdf is bundling libopenjpeg. | 22:53.57 |
| malc_ | sebras: i always fail at being subtle.. i was hinting at -j10 as the culprit | 22:54.26 |
| sebras | robin_watts_mac: tor8: ok.. so I pushed a commit that fixes the pkg-config printing problem. | 23:17.31 |
| malc_ | sebras: by the by, you guys cut the release but there's no tag in git for it as far as i can see | 23:18.06 |
| sebras | malc_: true enough... I'm sure it's still sitting in tor8's local repo. | 23:18.57 |
| malc_ | nor any new thirdparty zip was uploaded | 23:19.28 |
| | robin_watts_mac: btw. i know why it takes the same time.. the reason is simple the text is not clipped when doing a tiled rendering.. so it always renders, caches, hashes and so on for all the bloody charcters in the page | 23:23.26 |
| | tor8: lo, what i just said to Robin is probably of interest to you too | 23:23.56 |
| tor8 | malc_: I must have missed some part of the discussion (profiling, cache?) | 23:30.01 |
| | malc_: I forgot to push the tag, I have done so now | 23:30.46 |
| malc_ | tor8: basically rendering small tiles takes the same time as the very large one | 23:30.50 |
| | tor8: great! | 23:30.58 |
| tor8 | malc_: there is no thirdparty zip anymore, we use git submodules | 23:31.08 |
| | and we put the thirdparty libs directly in the source tarball | 23:31.17 |
| malc_ | but you used to place thirdparty after every release | 23:31.27 |
| | which isn't all that often | 23:31.37 |
| sebras | tor8: patch over at sebras/master | 23:33.09 |
| tor8 | malc_: that's odd, we should be using text and glyph bboxes to avoid rendering | 23:33.41 |
| malc_ | tor8: http://boblycat.org/~malc/main.pdf (very tall one page texty pdf) same happens with pdfs with images too | 23:33.59 |
| | you don't | 23:34.11 |
| | i just checked | 23:34.14 |
| | http://boblycat.org/~malc/ttest.c | 23:34.21 |
| | simple test | 23:34.23 |
| tor8 | sebras: why hide errors? | 23:37.41 |
| | that's ... not good if there are any | 23:37.49 |
| sebras | tor8: becuse I do not have libopenjpeg installed on my system, but instead rely on the one in thirdparty. | 23:42.18 |
| | tor8: this means I get the compilation errors whenever I compile. | 23:42.34 |
| oars | hi there | 23:42.53 |
| sebras | tor8: I have never seen those errors before, so I'm thinking that `` might hide stderr while $(shell ) does not. | 23:42.57 |
| | oars: hiya! | 23:43.00 |
| oars | anyone have any issues using mupdf under tiling window managers? | 23:43.09 |
| tor8 | sebras: the presence of thirdparty libs should prevent that detection no? | 23:43.18 |
| sebras | tor8: no. | 23:43.26 |
| | tor8: the detection is run before... | 23:43.35 |
| tor8 | sebras: `` is evaluated when executing the commands, $(shell) is evaluated by make | 23:43.50 |
| sebras | tor8: SYS_* is evaluated in Makerules, currently only based on $(OS). | 23:44.22 |
| | tor8: while the checks for thirdparty is done in Makethird. | 23:44.43 |
| | tor8: of course I could have moved the pkg-config calls to Makethird, but something tells me that this would be a bad idea. | 23:45.20 |
| tor8 | right. we could rejig that. but it's annoying. | 23:45.26 |
| sebras | oars: what problems are you experiencing..? | 23:45.33 |
| oars | trashing of the rendered pdf, I'll link a screenshot, easier explained that way | 23:45.51 |
| sebras | oars: excellent. | 23:45.59 |
| oars | http://i.imgur.com/4zEltdo.png | 23:49.31 |
| | so everytime I swap pages, or change zoom level the trashing changes on the renered pdf | 23:52.08 |
| | so it isn't constant | 23:52.11 |
| | I just built updf from source (1.2) to make sure the ubuntu install wasn't at fault | 23:52.25 |
| | also if I use the default window manager for ubuntu (Unity and the like) the trashing does not occur | 23:52.50 |
| | sebras: any ideas? | 23:56.19 |
| sebras | is back. | 23:57.18 |
| | oars: does the bad rendering differ depending on the size of the window? | 23:59.48 |
| | Forward 1 day (to 2013/03/02)>>> | |
IRC Logs
