| | <<<Back 1 day (to 2015/07/13) | 20150714 |
| thearr | hello everybody | 06:13.11 |
| mvrhel_laptop | henrys: so I am out tomorrow to go camping. back Thursday evening. Not sure if I will have cell service there | 06:36.06 |
| kens | chrisl, you have a minute for a font sanity check ? | 08:36.04 |
| chrisl | kens: I'm not sure sanity is my strong point right now..... | 08:37.46 |
| kens | Having trouble yourself ? | 08:37.58 |
| chrisl | Just over tired, I guess | 08:38.18 |
| kens | Let me finish up ths mail and send it to you, one second | 08:38.42 |
| chrisl | Okay | 08:38.53 |
| kens | OK the mail is on its way, the attachments were bigger than I realised or I'd have made a rar archive. | 08:41.58 |
| chrisl | So, does this go wrong when pdfwrite subsets the font, or when it doesn't? | 08:44.00 |
| kens | WHen it *doesn't* subset the font | 08:44.10 |
| | I haven't debugged the code, but.... | 08:44.27 |
| chrisl | But the rendered output it correct? | 08:44.36 |
| kens | No | 08:44.44 |
| | With the non-subset font the uumlaut is missing | 08:44.55 |
| | With the subset font it is not | 08:45.03 |
| chrisl | If you render the original file with gs, it's correct | 08:45.14 |
| kens | Yes the original is fine | 08:45.22 |
| | Err, I thnk | 08:45.27 |
| | Yes its OK | 08:45.54 |
| chrisl | So, presumably we're using the 3.1 cmap table for rendering | 08:46.15 |
| kens | I haven't debugged through the pdfwrite code yet, but from dumping the non-subset output of pdfwrite it looks like its just copying the 1,0 cmap and ignoring the 3,1 one | 08:46.27 |
| | chrisl, not only for rendering but also for subsetting | 08:46.39 |
| | Actually I'm incorrect there, there is a 3,1 table in the pdfwrite non-subset output | 08:47.08 |
| | SO now I'm confused again | 08:47.37 |
| | and teh pdfwrtite output font crashes ttfdump :-) | 08:47.48 |
| chrisl | So, possibly pdfwrite is writing the font with different parameters that cause the 1.0 cmap to be used instead of the 3.1 | 08:48.18 |
| kens | Yes that could be, though I can't thnk what would cause that | 08:48.31 |
| | It is labelled as a symbolic font | 08:48.42 |
| chrisl | Hmm, that's strange - does the original have an encoding? | 08:49.08 |
| kens | The real questoin in my mind, though, is 'shouldn't the 1,0 and 3,1 cmaps be the same ?' | 08:49.16 |
| | According to Marcos if we supply an Encoding it works | 08:49.30 |
| | But you aren't supposed to do that with a symbolic font | 08:49.44 |
| chrisl | Yes, but IIRC Acrobat behaves differently if you have a symbolic font with an encoding | 08:50.14 |
| kens | It does, yes | 08:50.20 |
| chrisl | And I think part of that difference is which cmap table it uses | 08:50.37 |
| kens | Could be I guess. | 08:50.52 |
| | I wonder if I mark the original font as symbolic and remove the encoding if it will behave the same. | 08:51.10 |
| | But really, the two CMAP tables should be compatible! | 08:51.24 |
| chrisl | AFAIK, there is no requirement for that to be case | 08:51.43 |
| kens | Then you always risk getting the wrong answer. | 08:51.55 |
| chrisl | Not if you are consistent with use of the cmap table(s) | 08:52.24 |
| | But it is bonkers....... | 08:52.35 |
| kens | Well, I'[m not certai that its possible to fix this, without removing the symbolic flag from the font. | 08:53.24 |
| | Or subsetting the font. | 08:53.33 |
| chrisl | Could you "subset" the font, but force all glyphs to be marked as used? | 08:54.47 |
| kens | Umm, possibly..... | 08:55.08 |
| | I could give it a try at least I suppose | 08:55.16 |
| | Trouble is, I htnk we generate a bunch more stuff that way, than by leaving the font alone. | 08:55.33 |
| | Basic problem I htnk is that thsi code needs to be rewritten so it actually works without the crazy kludges. | 08:56.04 |
| chrisl | The logic we apply for cmap choice (which is my best guess at what Acrobat does) is in /.pdfcharkeys in gs_ttf.ps | 08:56.24 |
| kens | Its the pdfwrite code that needs to be rewritten I thnk :-) | 08:56.52 |
| | GS matches Adobe in ths case | 08:57.05 |
| | I'll experiment a bit, thanks for the talk | 08:57.25 |
| chrisl | Yes, but seeing the "logic" we apply, might give a hint as to why the pdfwrite output behaves as it does | 08:57.34 |
| kens | I'm trying to figure out/remember why we apply the symbolic flag now, it may well be that its for compatibility with a stupidly old version of reader. | 08:58.11 |
| | Yeah: | 08:58.48 |
| | * Hack: make all embedded TrueType fonts "symbolic" to | 08:58.48 |
| | * work around undocumented assumptions in Acrobat Reader. | 08:58.48 |
| | */ | 08:58.48 |
| | I thnk I'll just run a cluster test and see what happens if I remove that (and test the customer's file as well of course) | 08:59.26 |
| chrisl | For non-symbolic fonts, Acrobat treats what it judges to be a notdef glyph as non-marking - that can be problematic with stupid (usually badly subsetted) fonts that have a real glyph where an a notdef is expected | 09:00.12 |
| kens | Well, the way things are at the moment, we can't have that 'hack' and at the same time get ths font correct. | 09:01.23 |
| | An yeah, if I remove the symbolic flag, then the result of the customer's file is correct. | 09:02.34 |
| | I have a nasty suspicion I looked at removing the hack some time ago, and wasn't able to ebcause it caused regressions, but lets see | 09:03.20 |
| chrisl | This really is down to Acrobat doing undocumented things when a symbolic font has an encoding..... | 09:03.37 |
| kens | I know :-( | 09:04.01 |
| chrisl | How about only applying the hack when subsetting the font? | 09:04.23 |
| kens | I was thinking about that yes | 09:04.31 |
| | Or more accurately, not makign the font symbolic if we aren't subsetting and the font is TrueType | 09:04.53 |
| | I'll look at that next. The problem is that we *don't* copy the font verbatim, some of it is still generated so I'm not completely sure what effect that might have. | 09:05.28 |
| | And teh fact that we don't copy it verbatim when not subsetting is also mad. | 09:05.47 |
| chrisl | The only other thing would be if pdfwrite could detect that the original font had an encoding, and only then force every glyph to be marked used, and push it through the subsetting code | 09:06.23 |
| | That way the extra stuff it generates would only happen for invalid input files | 09:06.50 |
| kens | Right now I'm not sure why the subset font works | 09:07.08 |
| | Oh wait, probably because we generate new CMAP tables | 09:07.25 |
| chrisl | Yeh | 09:07.30 |
| kens | WHch will be correct..... | 09:07.31 |
| chrisl | So, by doing that, you get the font data which matches the expectations of the surrounding PDF file | 09:08.12 |
| kens | I just checked and we defintely rewrite the 1,0 cmap, to match the actual used glyphs of course, so I guess that's a potential brute-force workaround :-( | 09:08.59 |
| chrisl | I think you have to | 09:09.54 |
| kens | Let me see what comes out of ths cluster run, but its looking more likely by the minute :-( | 09:10.15 |
| | Because, basiclaly, the two CMAP tables don't match. | 09:10.32 |
| chrisl | Indeed. And, honestly, that's not that rare...... | 09:11.09 |
| kens | I'm inclined to try the 'don't write as symbolic when not subsetting' first. | 09:11.18 |
| chrisl | Which will almost certainly pass the cluster test | 09:11.50 |
| kens | Given that the default is to subset and you have to specifically request full embedding, I'm not too bothered by that. | 09:12.41 |
| | Hmm removing the symbolic flag from TT fonts gave no cluster diffs..... | 09:22.48 |
| kens2 | Hmm, simply removing the symbolic flag doesn't work either | 09:44.29 |
| | Then I get a TT notdef glyph | 09:44.46 |
| | Looks like brute-force may be the only solution | 09:44.57 |
| rayjj | morning, all | 14:23.07 |
| henrys | hi rayjj | 14:23.33 |
| marcosw | morning | 14:25.37 |
| henrys | I'm hoping for a short meeting... got sick this weekend feel like crap | 14:27.50 |
| marcosw | i'm sorry that hear that. | 14:28.12 |
| | not the short meeting part, the other thing. | 14:28.21 |
| chrisl | henrys: hopefully nothing to serious | 14:28.32 |
| henrys | no just regular flu like symptoms, pretty sure I got it from my son. | 14:29.32 |
| | who was visiting | 14:29.38 |
| fredross-perry | sorry henry | 14:29.43 |
| henrys | 3 weeks before the big race this year which is kind of a bummer anyway | 14:30.08 |
| paulgardiner | Hope it clears up quickly | 14:30.09 |
| henrys | ... | 14:30.10 |
| kens | chrisl I thnk we should close bug #696080, I@m reasonably sure the problem has been addressed by the commit you pointed \t | 14:30.39 |
| henrys | jeong's xfa code is in my home directory if anyone wants to take a preview of it. | 14:31.08 |
| chrisl | kens: Er, oh, yes, I'd forgotten about that..... | 14:31.14 |
| henrys | it's named pdfv-[SHA].zip | 14:31.24 |
| kens | So had I ,I just saw it on Marcos' bug report | 14:31.28 |
| chrisl | Done.... | 14:31.54 |
| kens | :-) A nice easy one | 14:32.03 |
| chrisl | Yes , thanks Robin_Watts ...... :-) | 14:32.29 |
| Robin_Watts | henrys: It's MuPDF based, right? So I'll try and have a look. | 14:32.38 |
| henrys | Robin_Watts: yes, xfa has it's own folder so it should be pretty easy to look at. | 14:33.04 |
| chrisl | henrys: I hate to mention this when you're feeling delicate, but I've had some feedback about the greek and cyrillic additions to the URW fonts...... | 14:33.32 |
| henrys | I'm haggliing with him about GPL we might have to do this as a commercial only piece if I can't convince him of GPL | 14:33.57 |
| Robin_Watts | henrys: xfa? Or fonts? | 14:34.20 |
| henrys | chrisl: I skimmed a bug saying it wasn't complete, you've verified that? | 14:34.26 |
| chrisl | henrys: yes, that's resolved - my fault | 14:34.44 |
| henrys | Robin_Watts: xfa | 14:34.48 |
| chrisl | What I've been asked is: can we ask URW for AFM files for the three families? | 14:35.05 |
| Robin_Watts | If anyone is interested in trying a very early version of the gsproof stuff running on windows, let me know and I can put an archive up somewhere. | 14:35.27 |
| henrys | chrisl: I can ask them I don't see why that would be a problem. | 14:35.37 |
| rayjj | chrisl: can't we generate afm's ? | 14:35.44 |
| chrisl | The AFM files generated from the font files don't include kerning and ligature information | 14:35.55 |
| | rayjj: ^^ | 14:36.10 |
| rayjj | chrisl: oh, yeah. | 14:36.13 |
| chrisl | henrys: the second thing was there may be a missing glyph: CYRILLIC SMALL LETTER SCHWA (afii10846/uni04D9) | 14:37.01 |
| henrys | Robin_Watts: I'd throw that up and send an email to tech... michael will probably want to give it a go. | 14:37.21 |
| chrisl | Well, the glyph is missing, it's a question of whether that's intentional or an oversight | 14:37.38 |
| henrys | chrisl: okay I'll probably make a couple bugs for these things | 14:38.01 |
| Robin_Watts | henrys: I've been talking to Michael about it. He has the source :) | 14:38.03 |
| henrys | Robin_Watts: oh then nvm | 14:38.15 |
| Robin_Watts | but I think he's camping tuesday -> thurs this week. | 14:38.34 |
| henrys | geez 3 new customer bugs | 14:38.35 |
| chrisl | henrys: I can do that if you want - I'd offer to contact URW myself, but you at least (eventually) get replies...... | 14:38.40 |
| henrys | chrisl: yeah make the bugs and assign it to me. I have to talk about the "tour" with them anyway, let's keep the priorities straight | 14:39.23 |
| | rayjj: any progress on your bugs you sitll have 4 on the customer list? | 14:41.39 |
| | chrisl: how to proceed with your patch was the big question for this week. | 14:42.26 |
| | chrisl: do you want to have multiple reviewers or you can pick somebody to review but I think it should be reviewed because of its size. | 14:43.00 |
| chrisl | henrys: as far as I'm concerned, the remaining issue is the cluster..... | 14:43.00 |
| | henrys: I'm happy for anyone to review it - good luck! | 14:43.23 |
| marcosw | henrys: yes, and I haven't done anything about that yet. | 14:43.23 |
| | I can look at it today. | 14:44.09 |
| rayjj | henrys: progress on the one for jasper. I'm tempted to submit a patch just for the fast threshold conversion problems, since they didn't complain about the pixel placement mis-match | 14:44.22 |
| marcosw | chrisl: What was the repository/branch with the code? | 14:44.30 |
| chrisl | marcosw: it's in my repo, branch name build_consolidation | 14:44.57 |
| rayjj | henrys: that's bug 695929. | 14:44.58 |
| henrys | chrisl: have you merged kens stuff back to your branch? | 14:45.16 |
| chrisl | henrys: I did that last Wednesday | 14:45.28 |
| henrys | chrisl: great | 14:45.37 |
| chrisl | It was far less of a problem than I'd thought, tbh | 14:45.54 |
| rayjj | henrys: and as I mentioned last week, I don't know where to start on bug 696018 that I can't reproduce | 14:45.59 |
| henrys | I think Robin_Watts and I should be reviewers, if no objections. | 14:46.04 |
| chrisl | Fine | 14:46.15 |
| Robin_Watts | Do I get to object? :) | 14:46.35 |
| henrys | Robin_Watts: you do. | 14:46.44 |
| Robin_Watts | I'll gladly have a look. | 14:46.50 |
| henrys | anything else for the meeting? | 14:47.56 |
| | fredross-perry: are you occupied? I haven't been keeping up with what you are working on. | 14:48.41 |
| fredross-perry | Iâve been looking at the latest preview stuff for Android Studio, trying to see if I can get native C/C++ debuggin working for mupdf. | 14:49.25 |
| Robin_Watts | fredross-perry: If you can't get that to work currently, I wouldn't worry to much. | 14:50.01 |
| | They are at pains to point out it's still unfinished code. | 14:50.12 |
| fredross-perry | Iâm writing up some details of what Iâve learned so far, then Iâll probably drop it for a while. | 14:50.30 |
| Robin_Watts | and it won't be finished for 1.3 (I believe this is 1.3beta they have out now) | 14:50.32 |
| henrys | I've heard rumor Tor will be back early but that may mean 1 day early not sure ... | 14:50.42 |
| Robin_Watts | When is he due back? | 14:50.53 |
| fredross-perry | so let me know what I should be working on next, then. | 14:51.10 |
| chrisl | I thought Tor was due back rsn anyway? | 14:51.20 |
| henrys | july 27 | 14:51.35 |
| chrisl | I reckon sebras has been spying for him, anyway...... | 14:52.23 |
| Robin_Watts | Ah, 2 days after I leave. | 14:52.30 |
| | Seamless handover then :) | 14:52.38 |
| henrys | fredross-perry: not sure what's the most important now, should have an idea after the SO meeting. | 14:53.41 |
| fredross-perry | ok | 14:53.50 |
| henrys | off to skype for the next meeting... | 14:54.22 |
| marcosw | chrisl: I've been typing "cd ghostpdl/gs" for so long I'm not sure I can deal with this change. | 14:55.16 |
| chrisl | marcosw: courage! | 14:55.35 |
| Robin_Watts | marcosw: ln -s . gs | 14:56.20 |
| marcosw | chrisl: you don't want to know how long it took me to stop typing "git log | more" | 14:56.32 |
| sebras | chrisl: hiya! :) *reads* | 14:56.40 |
| chrisl | sebras: nothing serious - just accusing you of being Tor's mole whilst he's absent! | 14:57.08 |
| | marcosw: it should be fairly straight forward for the cluster code to cope with both directory structures just by checking for the existence of a file or two at a specific path | 14:58.11 |
| sebras | chrisl: well... I can tell you that he has been advising me on things that I have written about here, so I think he has had to bite his tongue not to log on... ;) | 14:59.07 |
| chrisl | sebras: I can't say I'm surprised - I'm rather impressed at his self control | 14:59.42 |
| sebras | agrees. | 15:00.23 |
| | chrisl: I was siding with robin when he claimed that we'd see tor online again in two weeks time... | 15:00.50 |
| chrisl | Indeed - I kept expecting someone to appear with the nick "not-really-Tor-honestly" | 15:01.56 |
| sebras | chrisl: maybe he was here... Guest49075 made futile attempts to greet robin the other morning! | 15:03.12 |
| chrisl | sebras: I'm surprised he didn't set up a torbot that would interject with sarcastic comments at random intervals | 15:04.12 |
| | <sigh> I think there are a few operating systems we could drop from our bugzilla..... | 15:04.26 |
| kens | Ancient versions of Windows would be good | 15:05.06 |
| | Mac SYstem 7-9 | 15:05.16 |
| chrisl | And BeOS? | 15:05.21 |
| kens | Isn't that still available ? | 15:05.32 |
| chrisl | I thought not - maybe I'm wrong. | 15:06.00 |
| kens | There's a BeOS 5.0 presonal edition but I don't know when it was last updated | 15:06.17 |
| chrisl | I know there's Haiku which is a sort of BeOS clone | 15:06.28 |
| kens | Yeah, a fork sort of | 15:06.40 |
| | I'd thnk we could drop it from Bugzilla | 15:06.58 |
| rayjj | yeah, but the point is, have we EVER had a problem reported with any of these (at least in the last 10 years) ? | 15:07.09 |
| chrisl | Well, I'm convinced: any page with "IE is EVIL!!!" at the top is okay by me ;-) | 15:07.27 |
| rayjj | chrisl: I agree! | 15:07.38 |
| kens | What page was that ? | 15:07.54 |
| | Oh I see | 15:08.03 |
| chrisl | We really, *really* don't support Windows 3.1, and probably not MacOS versions < 10, so..... | 15:08.29 |
| rayjj | chrisl: right, not even for paying customers | 15:09.06 |
| chrisl | Windows 9x is more complicated.... | 15:09.35 |
| rayjj | yeah, didn't we just have someone come in with that one ? | 15:10.03 |
| chrisl | They pop-up a couple of times a year | 15:10.19 |
| rayjj | anything that runs win32s _should_ be OK (even if it needs special build process) | 15:10.41 |
| chrisl | Exactly | 15:10.53 |
| | AFAICT, BeOS is kaput - it's mentioned in lots of places, but I can find any way to get it | 15:12.18 |
| Robin_Watts | I have the first bit of the plumbing for the gproof stuff done on android; a new 'P' icon on one of the menus. Hit that, and it generates the .gproof file, and reinvokes MuPDF on it to view it. When it closes down, it deletes the .gproof file. | 15:19.03 |
| | The newly invoked mupdf is reading the gproof file, but the page renderings are failing, cos I haven't built a gs exe. | 15:19.38 |
| chrisl | So I should probably look at the Android gs build :-( | 15:20.51 |
| Robin_Watts | chrisl: I have done that build in the past. Wasn't hard. | 15:22.15 |
| chrisl | Robin_Watts: It's more trying to make it easily repeatable | 15:23.03 |
| Robin_Watts | Trying to figure out the best way to do it. I have built separate exe's in the past and called them, but if memory serves, it's a bit of a hack. | 15:23.05 |
| | It may be better to build a lib and then drive it through the api. | 15:23.19 |
| chrisl | does android do shared libs? | 15:23.59 |
| Robin_Watts | chrisl: Yes. | 15:24.13 |
| | Well... | 15:24.16 |
| | libmupdf.so is the native code. | 15:24.24 |
| | I'd probably roll gs into libmupdf.so for simplicity. | 15:24.39 |
| | So a static lib that I could link into libmupdf.so would be idea. | 15:24.57 |
| | l | 15:24.59 |
| chrisl | Hmm, we don't have a way to make a static lib right now | 15:25.15 |
| Robin_Watts | chrisl: Ah. | 15:26.16 |
| | Not even with your shiny new stuff? | 15:26.24 |
| chrisl | No. I've avoided it because it adds an extra requirement onto the build | 15:26.53 |
| Robin_Watts | What extra requirement is that? | 15:27.10 |
| chrisl | ar | 15:27.16 |
| Robin_Watts | chrisl: Ah. | 15:27.40 |
| | Is that a problem? | 15:27.58 |
| chrisl | Probably not. But as we've managed without it so far, I didn't want to add it without a very good reason | 15:28.42 |
| | It's probably not going to be too horrible to add a new .a target. Previously I've always considered it as an additional step in the "normal" builds | 15:30.34 |
| Robin_Watts | Presumably we have a .dll target at the moment? | 15:31.39 |
| | This would be a .lib target with the same input objects? | 15:31.49 |
| chrisl | .so yes | 15:31.50 |
| | Essentially yes. | 15:32.13 |
| Robin_Watts | or are the build flags for .lib objects different to .dll ones? | 15:32.28 |
| chrisl | Not significantly | 15:32.48 |
| Robin_Watts | chrisl: Is that something that you can look at in the next day or so? Or should I look for a short term hack? | 15:33.35 |
| chrisl | Robin_Watts: I'll start on it properly tomorrow | 15:34.08 |
| Robin_Watts | If you're busy with something else I'll look at a hacked build just so I can get something running before I go. | 15:34.08 |
| | OK, then I shall park this and look at reviewing your stuff. | 15:34.37 |
| | Thanks. | 15:34.45 |
| fredross-perry | errand, biab | 15:39.34 |
| Robin_Watts | chrisl: "independendant". I like that almost as much as #EMXIF :) | 16:00.29 |
| chrisl | Robin_Watts: I never claimed I could type...... | 16:00.56 |
| Robin_Watts | chrisl: So the VS solution has projects for pcl/gs/xps as now? | 16:06.41 |
| | pcl depends on gs? xps depends on pcl and gs? | 16:07.09 |
| | And the ghostpdl project depends on the others? | 16:07.30 |
| chrisl | Sort of... it's explained in the commit message | 16:07.34 |
| Robin_Watts | Yeah, I understand the problem (from reading the commit message). | 16:07.55 |
| | I don't *quite* understand the solution. | 16:08.04 |
| | Does that mean that if you build ghostxps, it will build both gs and pcl first? | 16:08.26 |
| chrisl | It does, yes | 16:08.50 |
| | Which is a pain | 16:08.59 |
| Robin_Watts | There may be a better solution. You may have considered this and it won't work for some reason... | 16:09.14 |
| | When you build ghostscript, AIUI, it builds the graphics lib first, then builds the gs specifics ? | 16:09.30 |
| chrisl | Hmm, no, not really | 16:09.42 |
| Robin_Watts | ok, then I'm slightly confused. | 16:10.04 |
| | I thought (at least part of) the purpose of this stuff was to have it so that the graphics lib was a separate standalone section of code? | 16:10.35 |
| | shared between all the exe's. | 16:10.42 |
| chrisl | Somewhat, but not of the build | 16:11.22 |
| Robin_Watts | So the same .obj files will be produced as part of all 3 builds, but there is no definite shared makefile target? | 16:12.16 |
| chrisl | The problem is that there are *loads* of shared targets - we don't have (and can't have) a specific graphics library target | 16:13.02 |
| Robin_Watts | Would it be feasible for there to be a makefile target that was 'all the graphics lib objects' makefile target? | 16:13.21 |
| | I guess you've just said no :) | 16:13.28 |
| chrisl | No | 16:13.28 |
| Robin_Watts | I can't entirely see why not. | 16:13.55 |
| | (I'm not doubting you, my knowledge is not great enough here) | 16:14.10 |
| chrisl | The graphics library is not quite the same for every interpreter. It's just we can now share almost all the object files between the builds | 16:14.44 |
| | The main reason, right now, is the romfs | 16:14.59 |
| Robin_Watts | Is is possible to group the objects so we have "all the shared ones", "all the ones specific to pcl" etc ? | 16:15.44 |
| | Even if none of those groupings is a self contained runnable group. | 16:16.01 |
| chrisl | Probably. I can probably rearrange things slightly - I hate Visual Studio :-( | 16:16.46 |
| Robin_Watts | If it was possible to do that, then we could have separate projects in VS for those groupings. | 16:17.14 |
| chrisl | Oh, actually, I'm not sure that will work, because it will probably break the nmake command line builds | 16:17.40 |
| Robin_Watts | And thus each exe could depend on the appropriate ones. And parallel makes would work out. | 16:17.46 |
| chrisl | No, that won't work | 16:18.10 |
| Robin_Watts | Currently an "nmake gs" will implicitly depend on all those object files. | 16:18.39 |
| | I'm suggesting that gs will depend on graphics_lib_objs_for_gs explicitly. | 16:19.01 |
| | And that we have a project in VS that builds graphics_lib_objs_for_gs | 16:19.29 |
| chrisl | The problem is we'll get a clash between the dependencies in the makefiles, and the dependencies in the solution | 16:19.37 |
| | So either the plain nmake build won't work, or we'll hit the same problem with the solution | 16:20.07 |
| Robin_Watts | It's fine for the ghostscript target to still do 'make gs' at the same time as something else is doing 'make pcl' cos we know that by the time they are being run the make graphics_lib_objs_for_gs will have completed. | 16:20.31 |
| chrisl | It won't work for plain nmake | 16:20.59 |
| Robin_Watts | Why not? | 16:21.08 |
| chrisl | Because there won't be a gs dependency in the makefile on graphics_lib_objs_for_gs | 16:21.34 |
| Robin_Watts | Yes, there will. | 16:21.42 |
| chrisl | Then we'll hit the same problem we have now | 16:21.51 |
| Robin_Watts | No, we won't, AIUI, because we can set VS up so that nothing builds gs without graphics_lib_objs_for_gs being up to date. | 16:22.23 |
| | The makefile will still check those dependencies, but because they are already up to date, it will never do any builds. | 16:22.42 |
| | Hence no parallel make problems of things trying to write the same files at the same time. | 16:23.01 |
| chrisl | So the three (four?) projects all depend on the graphics_lib_objs_for_gs project? | 16:23.21 |
| Robin_Watts | chrisl: yes, (ish). | 16:23.54 |
| | I'd imagine that we have a 'core' of objs that are common to all interpreters. | 16:24.14 |
| | and then we have some gs specific ones. So gs depends on those specific ones + the core. | 16:24.35 |
| | and we have some pcl specific ones, so pcl depends on those specific ones + the core. | 16:24.53 |
| | etc. | 16:24.54 |
| | And we have projects for each of these subsets. | 16:25.05 |
| kens | XPS depends on PCL | 16:25.09 |
| Robin_Watts | And we can properly express the dependencies between them. | 16:25.17 |
| | kens: can you be more explicit please? | 16:25.37 |
| kens | SOme of the files required for gxps are in PCL | 16:25.51 |
| | So in order to build gxps you must build Ghostpcl | 16:26.02 |
| | Or this used ot be the ase I believe | 16:26.18 |
| Robin_Watts | kens: At the graphics library level, or at the interpreter level? | 16:26.31 |
| kens | interpreter level | 16:26.38 |
| | Nothing invalidates making a graphics lib | 16:26.48 |
| chrisl | It's the stuff in pl is used by both pcl and xps | 16:26.51 |
| Robin_Watts | I was talking about the graphics library dependencies. If there are interpreter level dependencies, then it may be reasonable to have xps depend on pcl (as the overhead won't be great). | 16:27.17 |
| kens | Yeah, merely mentoning it so it isn't forgotten | 16:27.35 |
| chrisl | I *think* I can probably make this work without significant changes to the makefiles | 16:27.45 |
| Robin_Watts | TBF the problem is not with MSVS here. It's the way we are abusing MSVS. | 16:28.07 |
| kens | G'night folks | 16:28.13 |
| Robin_Watts | Possibly we should structure the solution differently and have just one target, but with multiple different configurations. | 16:28.30 |
| chrisl | Well, one of the benefits of this is that it's *way* faster to build all the executables | 16:29.19 |
| Robin_Watts | chrisl: Oh, yes, I'm sure. | 16:29.27 |
| | But it does feel odd that building pcl will also refresh my gs exe. | 16:29.50 |
| | Which is a pain if I've made a hacky change to test something in pcl that breaks the gs build. | 16:30.14 |
| chrisl | Well, tbh, I was thinking maybe there shouldn't be a combined solution | 16:30.45 |
| Robin_Watts | oh, that'd be a nasty step back :( | 16:31.01 |
| chrisl | Well, the problem is: what happens with a pure Ghostscript distribution? | 16:31.33 |
| Robin_Watts | chrisl: You load the solution, the solution fails to find the pcl.vcproj files, and MSVC carries on quite happily. | 16:32.22 |
| | (with 'pcl (not found)' in the solution list) | 16:32.43 |
| chrisl | Robin_Watts: Yeh, and then everyone complains about the "error"..... | 16:32.55 |
| Robin_Watts | VS copes quite well with that case. | 16:33.00 |
| chrisl | But users don't :-( | 16:33.13 |
| Robin_Watts | chrisl: Well, we can write code to strip out targets from the xml easily enough. | 16:33.18 |
| chrisl | This was supposed to make the release process easier, not harder | 16:33.46 |
| Robin_Watts | chrisl: maintaining 2 solutions is a possibility. | 16:34.49 |
| | It's easy to have multiple solutions that share project files. | 16:35.04 |
| chrisl | Actually, probably just delete the solution from GS - we only supply a vcproj just now anyway | 16:35.13 |
| Robin_Watts | The dependencies between projects live in the solution files, I think. | 16:35.46 |
| | but actually, in what I described above, for a single language build, the dependencies in the makefiles are enough. | 16:36.15 |
| chrisl | Yes, so for the gs distro, there is only one project. For the full distro, you get the sln with the dependencies | 16:36.42 |
| Robin_Watts | chrisl: Is your intention to squash and push this? Or to push it in all it's glory? | 16:36.55 |
| | yeah. | 16:36.56 |
| chrisl | It'll have to be squashed - there are many commits in there that don't build | 16:37.23 |
| Robin_Watts | Well, my first pass through didn't spot anything massively unexpected. | 16:38.09 |
| | I'm going to squash here and look at the squashed version now... | 16:38.24 |
| chrisl | It looks like it will be quite easy (famous last words!) to add a target to build all the shared graphics lib objects - but as I need to finish in 20-30 mins, I'll look at that tomorrow | 16:41.13 |
| Robin_Watts | chrisl: Fab. | 16:42.42 |
| chrisl | (Note to self: don't leave a bottle of water filling and wander back to my desk - kitchen flooding may result) | 16:46.58 |
| Robin_Watts | oops. | 16:47.21 |
| chrisl | No flood, just a little puddle - I remembered almost just in time | 16:47.51 |
| | Robin_Watts: the thing I didn't touch was the xcode stuff - I know absolutely nothing about that.... | 16:48.08 |
| Robin_Watts | chrisl: I don't blame you at all. | 16:52.51 |
| | xcode should be sealed in concrete and dropped at sea. | 16:53.05 |
| chrisl | Does anyone use it? | 16:53.32 |
| Robin_Watts | xcode? Or our xcode project? | 16:56.06 |
| | No one sane uses our xcode project. | 16:56.12 |
| chrisl | Should we drop it, then? | 16:56.33 |
| Robin_Watts | Seems reasonable to me. | 16:57.49 |
| | IIRC it was just a thing that called out to make anyway. We can probably jump start it again (or start from scratch) if anyone wants it. | 16:58.22 |
| chrisl | I assumed it was similar to the Windows projects - really just to aid debugging | 16:58.59 |
| Robin_Watts | chrisl: Yes, but I long since decided that I'd rather gnaw my own leg off than use xcode. | 16:59.27 |
| chrisl | It does seem to have your name (and no one else's) plastered all over it! | 17:00.11 |
| Robin_Watts | yeah, I did it in a fit of enthusiasm cos I'd a) just done the MSVC ones, and b) just got a mac. | 17:00.40 |
| chrisl | Well, I hope you learned your lesson ;-) | 17:01.13 |
| Robin_Watts | You've seen my new shiny non-mac laptop, right? :) | 17:03.37 |
| chrisl | Once it finally worked | 17:04.21 |
| Robin_Watts | "old-stuff" ? | 17:04.22 |
| chrisl | Like xcode - for reference, to be updated etc | 17:04.57 |
| Robin_Watts | I wonder if we should just delete it. | 17:05.25 |
| | If people want stuff from there, we'll put it back and update it on demand. | 17:05.35 |
| chrisl | I think the only thing to be updated is the winrt stuff, the rest I'll probably remove | 17:05.40 |
| Robin_Watts | Where did pl/realmain.c go? | 17:06.55 |
| chrisl | pcl/pl | 17:07.05 |
| Robin_Watts | Why hasn't this picked it up as a copy/rename then? | 17:07.20 |
| chrisl | It should have - I think | 17:07.46 |
| Robin_Watts | Maybe gitk is just incapable of displaying it like that. | 17:08.03 |
| chrisl | git log --follow on it shows the entire history, so at some level, git knows what's going on | 17:09.10 |
| | Robin_Watts: I don't think git classes moving outside the current directory as a "rename" | 17:10.20 |
| Robin_Watts | chrisl: I still see a "# FIXME: use configure to pull in" in Makefile.in | 17:11.41 |
| | And some suspicious trailing spaces/tabs there. | 17:11.49 |
| | FEATURE_DEVS looks like it has a tab in it in particular. | 17:12.56 |
| chrisl | Yes, not too bothered about that - it's only whitespace. I forgot about the FIXME, I'll sort that out | 17:14.29 |
| | Actually, I think I'll just delete that FIXME - it's not really necessary. Which may be what I decided and just forgot to delete the comment | 17:16.08 |
| marcosw | chrisl: you probably already know this, but in the build_consolidation branch "make ; bin/gpdl" seg faults . | 17:19.08 |
| chrisl | marcosw: I didn't know - but I knew it didn't work. | 17:20.51 |
| | It's purely there so we have a target which contains all the interpreters, ready to put the real language switching stuff into | 17:21.52 |
| marcosw | chrisl: is there a document that describes what changed (i.e. the GhostPCL binary ends up in bin/gpcl6 rather than main/obj/pcl6)? | 17:23.02 |
| chrisl | No document, no. But it should be pretty self explanatory | 17:23.40 |
| marcosw | reminds me of an easter egg hunt :-) | 17:24.06 |
| chrisl | There are only three exes and all in the same place! | 17:24.29 |
| Robin_Watts | {,debug,mem}bin/{gs/pcl/xps} right | 17:25.12 |
| chrisl | {,debug,mem}bin/{gs/gpcl6/gxps} | 17:25.53 |
| Robin_Watts | {,debug,mem}bin/g{s/pcl6/xps} :) | 17:26.16 |
| | I've squashed everything down to a single commit. | 17:26.43 |
| chrisl | Yes. it always bugged me that pcl6 wasn't gpcl6 | 17:26.50 |
| Robin_Watts | git diff --follow HEAD~1 -- COPYING | 17:26.57 |
| marcosw | I cleverly use variables for directories in the cluster code, so changing ghostpdl/gs to ghostpdl was trivial. Unfortunately the binary names are hard coded and appear in multiple places. So I have to fix that first. | 17:27.05 |
| Robin_Watts | still shows that as a complete file deletion. | 17:27.06 |
| | marcosw: Just copy the files to the old names. I think that's what I hacked the cluster to do for various renames in mupdf. | 17:27.36 |
| marcosw | Robin_Watts: I will, but have to copy them from the right place... | 17:28.10 |
| chrisl | Robin_Watts: I think that's because COPYING moved to a new directory - hence git treats it as a git rm/git add operation | 17:28.46 |
| Robin_Watts | gitk shows it correctly. | 17:29.00 |
| chrisl | <shrug> | 17:29.41 |
| marcosw | chrisl: is looking for ghostpdl/ghostscript.vcproj a reasonable way to decide if it's the new directory structure? | 17:31.41 |
| chrisl | marcosw: my personal choice would be ghostpdl/Makefile.in - since the cluster is unix based, after all | 17:33.40 |
| | I really do have to go now - I'll check back in a couple of hours (if I feel up to it) | 17:44.44 |
| Robin_Watts | chrisl: You go. I'll keep bashing. | 17:44.56 |
| chrisl_away | Having said that, my ride is now 5 minutes late....... | 17:45.51 |
| henrys | I didn't like hearing there are xps dependencies in pcl maybe kens meant pl (the shared stuff) for pcl pxl and xps? | 19:50.13 |
| chrisl_away | It is pl - as I mentioned just after | 19:52.12 |
| henrys | thanks chrisl_away sorry to bug you | 19:54.55 |
| chrisl_away | No problem - lurking just in case | 19:55.16 |
| Robin_Watts | chrisl: I'm as happy as I can be with the commit. Can't see anything I haven't mentioned. | 20:12.35 |
| chrisl_away | Robin_Watts: OKay, thanks. I'm part way through messing with the Windows project stuff - but I'll have to finish it in the morning. Suffering brain fade...... | 20:13.38 |
| fredross-perry | Robin_Watts: thoughts about important mupdf bugs I can look at? | 21:33.16 |
| henrys | fredross-perry: from workflowy you had icloud, qt pricing and study pspdfkit | 21:52.32 |
| | as well | 21:52.41 |
| fredross-perry | yes | 21:52.51 |
| Robin_Watts | fredross-perry: There are no massively urgent mupdf bugs at the moment. | 23:05.49 |
| fredross-perry | thanks | 23:05.56 |
| Robin_Watts | There may well be some Android UI stuff you can help with with the gproof stuff very soon. | 23:06.19 |
| | Forward 1 day (to 2015/07/15)>>> | |
IRC Logs