| | <<<Back 1 day (to 2015/11/11) | 20151112 |
| xace | i can't seem to find a tag for v1.8 in the git repository, am I doing something wrong ? | 00:31.15 |
| | the remote im connecting to is: git://git.ghostscript.com/mupdf.git | 00:32.35 |
| sebras | xace: I think tor8 may have forgotten to push the 1.8 tag for commit 1548b9b | 00:40.10 |
| | xace: this channel is logged so I'm sure he will notice and fix this tomorrow. thanks for the heads up! :) | 00:40.40 |
| xace | alright. cool ill checkout commit 1548b9b | 00:40.58 |
| sebras | xace: this is the commit that bumps the version number so it has to be where the tag would go. | 00:41.28 |
| | kens: morning! | 07:52.03 |
| kens | Morning sebras | 07:52.20 |
| | chril did you see Hin-Tak's post on ft-devel ? | 10:33.16 |
| chrisl | Nope | 10:34.22 |
| kens | Apparently the MS Font Validator tool is open sourced under the MIT licence | 10:34.43 |
| | There's a link to github for it | 10:34.58 |
| chrisl | I doubt the open source version will be any more use than the M$ version..... | 10:36.44 |
| kens | I've found the MS one to be useful before | 10:36.55 |
| | And you can point people at it when they claim there's nothing wrong with their font | 10:37.09 |
| | I've never seen a font it didn't have *something* to say about :-) | 10:37.25 |
| chrisl | True, but then it also reports all sorts of heinous problems with fonts that almost every consumer reads without a problem :-( | 10:37.50 |
| kens | Sure, but that's because people have got used to accepting knackered fonts.... | 10:38.10 |
| chrisl | Ha! "This testing ensures that fonts meet Microsoft's high quality standards and perform exceptionally well on Microsoft's platform." | 10:54.40 |
| kens | Yeah right...... | 10:54.56 |
| chrisl | Oddly, it doesn't seem to come with a VS sln or project | 10:55.43 |
| kens | Just a makefile ? | 10:56.10 |
| chrisl | As far as I can see | 10:56.17 |
| kens | Even MS developers don't like solutions :-) | 10:56.23 |
| chrisl | Doesn't seem to work with nmake, though | 10:58.05 |
| kens | Not looking good then, doesn't build on Linux and doesn't buld on WIndows... | 10:59.22 |
| | And an awful lot of Windows developers won't have a clue how to build with no solution | 10:59.46 |
| chrisl | Ah, installing a *shed* more mono related libs gets it build on Linux..... | 11:05.15 |
| kens | I'd assumed you had it all already | 11:05.32 |
| chrisl | So did I.... | 11:05.49 |
| kens | :-D | 11:05.58 |
| Robin_Watts | kens: Presumably a solution wouldn't be hard to knock up for it? And if we did so, is there maybe mileage in sticking it up on our website as a tool for other people to use to verify fonts? | 12:14.19 |
| | Certainly it could be a stick to beat people with. | 12:14.28 |
| | Oh, it's on github? We should offer them a solution :) | 12:15.05 |
| chrisl | Given that it's been available from MS for free for *years* and almost no one seems to bother with it...... | 12:15.56 |
| | It's more noteworthy that MS didn't include a project or solution - I'm assuming they have one for their own use | 12:20.24 |
| Anderson_ | help | 12:52.03 |
| kens | I guess there's no helping some people.... | 13:03.34 |
| henrys` | chrisl: I did go through and move the icc manager to lib ctx, but it's not pleasing and there's still a problem with a gc header, I can fix the gc problem easy enough. but I'll let you and michael look at it now and see if we really want to do this. I know you guys say opaque pointers and hidden methods are a performance burden but changing 22 files to make this changes is a huge burden maintenance/safety wise. | 14:14.39 |
| | it's on my repo | 14:14.45 |
| | sorry I meant hidden members | 14:17.17 |
| Robin_Watts | opaque pointers and hidden members are essential for modularity. | 14:21.27 |
| chrisl | henrys`: TBH, I'd envisaged keeping the pointer in the imager/graphics state - I'd envisaged moving the "originating" pointer to the lib_ctx was to ease initialisation | 14:21.38 |
| Robin_Watts | We can always use inline functions defined in headers to alleviate that problem if it turns out to be performance critical. | 14:21.51 |
| Robin_Watts | scuttles back under SOT rock. | 14:22.15 |
| chrisl | Actually, I would prefer it if the contents of the icc manager were manipulated via accessor methods, but I think that's a much larger proposal | 14:23.42 |
| henrys` | chrisl: I could do it that way. I guess I find the code confusing that way though. Anything in the gstate be an actual PS thing affected by gsave and grestore, but yes I take your point. | 14:25.49 |
| | poorly said, it doesn't seem like it belongs in the gstate. | 14:27.13 |
| chrisl | henrys`: Yes, I agree, ideally only things affects by gsave/gsrestore should be in the graphics state..... but that wasn't the problem I was thinking about solving yesterday | 14:27.21 |
| | s/affects/affected | 14:27.35 |
| henrys` | chrisl: lib ctx was also a problem without accessor methods, amonst other things the only way I could figure out who was using the fontdir in the ctx was to yank it out of the structure and see where the code failed to compile. | 14:30.15 |
| | I feel like we need intense restructuring/refactoring in gs but I don't feel we have the manpower to deal with the fallout of errors introduced. | 14:32.00 |
| chrisl | There seems little point, anyway, if we are hampered by never changing the API | 14:32.35 |
| henrys | chrisl: which API? device, front end? I don't see anything we can't change, we just don't have the manpower to do the "upheaval" thing | 14:39.40 |
| | Robin_Watts: get out from under that rock, you said it was a performance problem ;-) | 14:40.31 |
| | kens, chrisl can you make it over to skype? I wanted to talk about a potential new customer. | 14:41.43 |
| kens | text ? OK | 14:41.53 |
| | couple minutes | 14:41.57 |
| Robin_Watts | henrys: No. I said that we should do what's cleanest in the code, and *if* there is a performance problem, then look at ways to mitigate it. | 14:42.00 |
| kens | OK I believe I'm on Skype.... | 14:43.00 |
| henrys | pokes the bear | 14:43.02 |
| chrisl | Hmm, my skype client just had some kind of embolism - I'll be a few minutes..... | 14:43.08 |
| kens | My Sjype wants to insall upgrades :-( | 14:43.29 |
| henrys | I guess I can do it with customer numbers here | 14:44.50 |
| kens | 171.579 662.224 240.84 -240.84 reI believe I'm there.... | 14:45.15 |
| | I see you as online henrys | 14:45.39 |
| chrisl | I'm just trying to remember my skype credentials - should be a few moments | 14:46.41 |
| henrys | kens, chrisl: nvm I'm using customer numbers. | 14:46.56 |
| kens | OK up to you | 14:47.47 |
| henrys | I have been talking with customer #9 about PCL for their printers. They are going forward with evaluation next week. Last time we did this manpower requirements were more than 1 person, you may be helping me with that project. We may hire too. | 14:48.14 |
| | s/for their printers/for their print system | 14:48.39 |
| kens | 171.579 662.224 240.84 -240.84 reIntriguing | 14:48.50 |
| | 171.579 662.224 240.84 -240.84 reStupid paste :-( | 14:48.59 |
| | Intriguing that this customer wants that | 14:49.18 |
| | Not too sure what I can do to help, I guess it depends what they want | 14:49.39 |
| chrisl | henrys: if the load is going to be significant, we're going to struggle | 14:50.08 |
| kens | To a gegree we are struggling now | 14:50.28 |
| | degree* | 14:50.34 |
| chrisl | Well, by significant, I pretty much mean anything other than trivial | 14:51.27 |
| kens | taking 1 person out is going to mean nothing new gets done and very likely the customer bug list will increase. The free user bug list will also increase of course | 14:52.00 |
| | Its only 3 weeks untli the staff meeting, is anything likely to happen before then ? | 14:52.32 |
| henrys | the irony of it is that entire framework for language switching was done at their request and here I am rippin g the entire thing out. | 14:52.40 |
| kens | Ah, but to replace it with somethign that might actually work :-) | 14:52.59 |
| henrys | kens: engineers start reviewing ghostpcl Monday | 14:53.05 |
| kens | Well, OK that's earlier than I expected | 14:53.20 |
| | TBH 171.579 662.224 240.84 -240.84 reI don't khge lot about PCL or our implementatoin, I'll answer what I can (I assume ths will be in a US timezone ?) | 14:54.03 |
| | keyboard playing silly buggers again, probably needs fresh batteries...... | 14:54.31 |
| henrys | it's possible it all goes very smoothly, they just plug it in with basic argc, argv control and their done. | 14:54.45 |
| kens | eWithout knowing more about what they want/expect, its hard to say | 14:55.16 |
| chrisl | Are they going to be happy with the dialect of PCL we do? | 14:55.21 |
| henrys | chrisl: I don't anticipate that will be a problem, that was never the issue last time anyway | 14:56.33 |
| chrisl | So, broadly, what were the issues last time? | 14:56.54 |
| henrys | chrisl: the language switching stuff was the worse part: I think you know about the horror main loop in plmain.c - but it does serve a purpose. It's documented somewhat in pltop.h:77 | 15:00.41 |
| chrisl | henrys: but this time they are only (for now) interested in PCL? | 15:01.19 |
| kens | Presumablyy they already have a PS/PDF solution..... | 15:02.03 |
| chrisl | One would hope...... | 15:02.12 |
| kens | and nobody cares about xps | 15:02.15 |
| henrys | chrisl: that's supposed to switch between PCL, XL and now XPS and be separate from their stuff. | 15:02.27 |
| chrisl | So they want XPS too? | 15:02.59 |
| henrys | oh forgot to mention XPS, yes | 15:03.06 |
| kens | Uhuh | 15:03.12 |
| chrisl | That's a bigger concern :-( | 15:03.20 |
| kens | well that means Tor will have to be involved too | 15:03.21 |
| henrys | or michael | 15:03.29 |
| kens | We already know hte XPS implementation in Gxps has slipped behind MuPDF | 15:03.41 |
| henrys | anyway let's see what happens... just giving you a "heads up" | 15:04.30 |
| Robin_Watts | kens: AIUI, we synced the two not that long ago. | 15:04.40 |
| kens | Well, ncie to have some advance warning | 15:04.51 |
| | Robin_Watts : you mean the OXPS fix ? I'm not certain that is an absolute synch | 15:05.15 |
| Robin_Watts | kens: No, I thought we'd done a sync BEFORE the oxps one. | 15:06.41 |
| tor8 | kens: the muxps and gxps implementations should have the same bug fixes in it, there's been very little actual work other than updating it for mupdf library changes | 15:06.41 |
| kens | Robin_Watts : I have no idea. I'm prepared to take people's woprd for it, I have not looked, but the fact is that we know of at least one recent omission, are we certain there are no others ? | 15:07.27 |
| | Its not like we do anythign with XPS very often I grant you | 15:07.57 |
| tor8 | kens: we support ZIP64 in muxps, not in gxps. not sure if that change made it over as well. | 15:07.58 |
| Robin_Watts | kens: no, but it shouldn't be TOO hard to do a gitk -- source/xps on a mupdf checkout and then look to see if the same changes have been applied to gs. | 15:08.14 |
| chrisl | AFAIK, we still use expat in gxps | 15:08.29 |
| kens | Robin_Watts : I wouldn't even know where to start with that | 15:08.52 |
| Robin_Watts | "gitk -- source/xps" will open a gitk window that shows all the commits that have changed source/xps :) | 15:09.34 |
| kens | Yeah but I wouldn't be able to tell which ones are MuPDF specific and which ones are not | 15:10.09 |
| Robin_Watts | kens: That's what the commit messages are for :) | 15:11.16 |
| tor8 | hm, there seem to be a handful of bug fixes that haven't made it across. | 15:11.21 |
| kens | So not an entirely unfounded concern then..... | 15:11.45 |
| henrys | mvrhel_laptop: lots of logs to read today :-( | 15:14.44 |
| mvrhel_laptop | uhoh | 15:49.33 |
| | henrys: I agree with chrisl that we need methods for these things rather than doing the operations on a lib_ctx member variable directly all over the code | 15:59.17 |
| | having it in the lib_ctx does make more sense since we have only the one instance | 16:00.00 |
| | I have no doubt that there are going to be issues with all these changes though. | 16:00.41 |
| tor8 | kens: I've copied several XPS fixes on ghostpdl tor/master for you to review :) I'm going out for a couple of hours now, will check back tomorrow and see if there are more fixes hidden further back | 16:01.02 |
| kens | tor8 I'm not sure I would have anything to contribute in terms of a review, but I'll look at it | 16:03.30 |
| mvrhel_laptop | Robin_Watts: tor8: Quick question for you. In the pdf_page_s structure, what is the me pdf_obj member variable. It appears to be related to the contents but it is not clear to me. | 16:17.19 |
| Robin_Watts | IIRC... the pdf_obj is the pdf object that represents the page in the file. | 16:18.09 |
| mvrhel_laptop | I see | 16:18.37 |
| Robin_Watts | You could think that the pdf_page structure is really just an unpacked in memory version of that pdf_obk | 16:18.48 |
| mvrhel_laptop | ok that makes sense | 16:19.07 |
| kens | tor8 (for the logs) I don't really understand the implications of the gradient fix, but I can't see anything actually wrong with it. The others look fine, I did't look at the WIP one. | 16:27.31 |
| henrys | mvrhel_laptop, and rayjj for the logs: I have successfully campaigned to make Veteran's Day an official Artifex Holiday beginning 2016, so when you don't show up Veteran's day next year you won't be AWOL ;-) | 17:11.10 |
| mvrhel_laptop | ha | 17:11.20 |
| | I was here for most of the morning... | 17:11.26 |
| henrys | I had to give up Boxing Day though | 17:11.33 |
| | marcosw: ping | 17:36.48 |
| mvrhel_laptop | bbiab | 18:27.15 |
| henrys | chrisl: I completely agree the imager state should be removed, it's not worth it. | 19:46.15 |
| faLUCE | hello, how can I remove 300 pts from left, 200 from up, 100 from right and 400 from bottom of mypdf ? | 21:36.24 |
| | hello, how can I remove 300 pts from left, 200 from up, 100 from right and 400 from bottom of file.pdf (multiple pages) ? | 21:38.49 |
| Robin_Watts | faLuce: Is this a one off operation? Or something you want to do to lots of pdf files? | 21:40.52 |
| faLUCE | Robin_Watts: in just one file with multiple pages | 21:41.16 |
| Robin_Watts | faLuce: All the pages the same size? | 21:41.49 |
| faLUCE | Robin_Watts: yes | 21:42.01 |
| Robin_Watts | if it was me: mutool clean -difggg in.pdf out.pdf | 21:42.10 |
| faLUCE | Robin_Watts: ? | 21:42.22 |
| Robin_Watts | That gives you a new file that should be easy to edit. | 21:42.29 |
| | basically it decompresses the old file. | 21:42.40 |
| | Then I'd load it into emacs and look for the page definitions. | 21:42.51 |
| | There will be a /MediaBox [0 0 1000 1000] or something. | 21:43.07 |
| | and hopefully all your pages will look the same. | 21:43.18 |
| faLUCE | Robin_Watts: no, there should be an easier solution. | 21:43.38 |
| Robin_Watts | Then I would replace /MediaBox [0 0 1000 1000] with /MediaBox [300 400 900 800] | 21:43.59 |
| | Ok, well, good luck. | 21:44.05 |
| faLUCE | Robin_Watts: thanks | 21:44.23 |
| henrys | odd I'm getting a compile fail on the cluster I can't reproduce on my machine. The compile failure does look correct, I wonder why I don't see it here | 22:05.33 |
| mvrhel_laptop | yeah! I am finally drawing/creating some pdf content with mutool create with only using pdf_write_document and not the pdf-write device | 22:16.42 |
| | sticking in the content stream into the pages->content indirect reference | 22:17.17 |
| | now, I can finally start working on the resource additions | 22:17.29 |
| henrys | mvrhel_laptop: the other part of the log to read was customer #9 is reviewing PCL and XPS, if you know anything off the top of your head that needs fixin' in XPS say something. | 22:28.53 |
| mvrhel_laptop | henrys: I don't know of anything that is broken. Are there any open bugs for gxps? | 22:30.08 |
| | looks like 12 | 22:30.23 |
| | 696316 looks like a problem.... | 22:31.03 |
| henrys | indeed it does ugh | 22:31.53 |
| mvrhel_laptop | henrys: if you want me to look at a few of these tomorrow I can | 22:32.13 |
| henrys | mvrhel_laptop: don't spend a lot of time but if you can give them a quick look | 22:32.38 |
| mvrhel_laptop | we have had a house guest all this week and into early next week which as affected my efficiency. I will have a look at 696316 tonight. I am at a good spot to take a break for a day to review them | 22:33.32 |
| | s/as/has/ | 22:33.39 |
| | need to push my mupdf branch to my repos | 22:34.08 |
| henrys | mvrhel_laptop: great. I actually ran through all the comparefile locally after fixing the gc stuff. We'll see what mr cluster says | 22:37.35 |
| mvrhel_laptop | cool | 22:37.57 |
| tor8 | Robin_Watts: yes, pdf_page is just the pdf_obj unpacked into a C struct. we could make that a much thinner lazily-loaded shim with accessor functions instead. | 23:32.13 |
| | I think that's the right way to approach this when we start editing pages etc, so we don't get things out of sync | 23:32.50 |
| | we can talk more about it later, I need to go to bed now | 23:33.04 |
| | Forward 1 day (to 2015/11/13)>>> | |
IRC Logs