| | <<<Back 1 day (to 2014/02/09) | 2014/02/10 |
| Robin_Watts | tor8: Morning | 13:00.00 |
| tor8 | Robin_Watts: morning. | 13:00.27 |
| Robin_Watts | So, I'm sick of fonts. | 13:00.47 |
| kens | sympathises with that | 13:01.04 |
| Robin_Watts | So I've gone back and stared at this array parsing stuff again. | 13:01.04 |
| | and I did a quick test on the file that has "0.0 Tc" in the middle of the TJ array. | 13:01.33 |
| | It turns out that if I change 0.0 to 100, then I can see a difference in acrobat. | 13:01.52 |
| kens | Oh that's bad | 13:02.00 |
| Robin_Watts | So acrobat is actually honoring the Tc. | 13:02.05 |
| tor8 | Robin_Watts: do we honor it? | 13:02.21 |
| Robin_Watts | No. | 13:02.28 |
| kens | What does GS do ? | 13:02.34 |
| | I suspect it throws an error.... | 13:02.40 |
| Robin_Watts | Oh. hmm. | 13:02.45 |
| kens | Can you give me the filename and I'll look ? | 13:03.02 |
| | Its barely possible we might cope with that | 13:03.21 |
| Robin_Watts | I was assuming that acrobat honors it because it leaves a gap between chars. | 13:03.43 |
| | but it might just be that it's interpreting it as a number in the array. | 13:03.43 |
| | I need to check what happens with a Tw. | 13:03.43 |
| kens | Good point | 13:03.55 |
| | It may just throw away the Tc | 13:04.03 |
| Robin_Watts | kens: tests_private/pdf/sumatra/916_-_invalid_argument_to_TJ.pdf 916.pdf | 13:04.06 |
| kens | OK I'll look quickly thanks | 13:04.14 |
| Robin_Watts | Ok, so the array in question is [(Hybrid) 0.0 Tc -278 (Dual) 0.0 Tc -178 (IGBT) ... ] TJ | 13:05.36 |
| | And that appears on screen as "Hybrid Dual IGBT" | 13:05.51 |
| | If I change it to: [(Hybrid) 100 Tc -278 (Dual) 100 Tc -178 (IGBT) ... ] TJ | 13:06.14 |
| | then it appears on screen as "H y b r i d" | 13:06.31 |
| kens | The it seems ot me its honouring the Tc | 13:06.47 |
| Robin_Watts | So it's clearly honoring the Tc. | 13:06.57 |
| | BUT... it's not sending the (Hybrid), THEN setting the Tc. | 13:07.13 |
| kens | Horrible | 13:07.13 |
| Robin_Watts | It's setting the Tc, THEN sending the hybrid. | 13:07.23 |
| | Let me try resetting the Tc later in the array. | 13:07.31 |
| tor8 | Robin_Watts: so, it's buffering up the array, spots the Tc in the middle and changes the state, which then takes effect at the TJ operator | 13:08.01 |
| kens | Robin_Watts : I suspect it won't 'send' the (Hybrid) until it encoutners the TJ, by which time the Tc has been altered | 13:08.08 |
| tor8 | so to match acrobat, we need to (a) create a temporary array for the TJ operator, and (b) respect other state changing commands in the middle of the array | 13:09.00 |
| kens | It seems like its behaving in a stack-based fashion, like PostScript | 13:09.09 |
| tor8 | kens: yeah... that'd be the easiest, but the mupdf operator stack is only 6 deep (the biggest needed to hold a matrix) | 13:09.41 |
| | and it only holds numbers | 13:09.50 |
| kens | tor8 I didn't mean you shoujld do it, just that's how it looks | 13:10.00 |
| tor8 | non-number objects get parsed and stashed in a special slot (for marked content, and inline images, etc) | 13:10.23 |
| kens | IIRC the PDFRM says specifically that Acrobat doesn't behave like that (stack-based) but some things might | 13:10.38 |
| tor8 | kens: yeah, so it'd be the easiest way to do it, if we had a stack-based implementation :) | 13:10.54 |
| kens | WHich is why I think GS might just work.... | 13:11.03 |
| Robin_Watts | Ok, yes if I do [(foo) 100 Tc (bar) 0 Tc (baz) ] TJ then the whole string is sent as if it was 0 Tc throughout. | 13:11.08 |
| | That's easyto match, I think. | 13:11.14 |
| kens | Yes that's what I would expect | 13:11.18 |
| tor8 | Robin_Watts: right. that's a fairly sane handling of it all. | 13:11.53 |
| | use the state in effect at the TJ command | 13:12.08 |
| | the problem is what to do with the stack of numbers and creating the array | 13:12.41 |
| kens | GS does indeed cope with the 'Tc' in the middle of the array in the same way as Acrobat | 13:13.23 |
| tor8 | Robin_Watts: our stack handling assumes the stack is empty between the operators | 13:13.56 |
| Robin_Watts | tor8: Our old code used to only accept Tc and Tw there. | 13:14.25 |
| tor8 | Robin_Watts: but with this array stuff, we don't have an easy way to know how many operands to pass to the operator | 13:14.34 |
| Robin_Watts | If I do the same, it's easy to match stuff, I think. | 13:14.38 |
| tor8 | Robin_Watts: if we say we only accept operators that take one (1) argument, it should be easy enough | 13:14.56 |
| | then we can lazily stash away the last number into the array as we come across them | 13:15.18 |
| Robin_Watts | yeah. gimme a mo, and I'll run some tests and show you what I've got. | 13:15.33 |
| tor8 | and let and Tc and Tw operators consume the number before it ends up in the array. | 13:15.36 |
| | anyway, I'll leave you to it | 13:15.50 |
| Robin_Watts | ooh, a file stopped giving errors with the new code, and another has diffs. bmpcmping now. | 13:26.24 |
| | oh, right, that one. | 13:30.53 |
| | tor8: I've pushed the commits to robin/master, and am running tests again. Going to grab some lunch. | 13:35.01 |
| tor8 | Robin_Watts: that do-while(0) looks a bit pointless | 13:58.16 |
| Robin_Watts | tor8: It's so we can break out | 14:11.07 |
| | oh, and I missed an fz_throw! | 14:11.41 |
| | Updated patch | 14:12.11 |
| tor8 | Robin_Watts: break out of what? | 14:13.14 |
| Robin_Watts | hopefully the new patch makes more sense. | 14:13.55 |
| henrys_ | Happy Monday! | 14:14.42 |
| tor8 | so you're wrapping it in do/while so you can skip past the throw? | 14:14.47 |
| | this function is causing my brain to melt down. do/try/do/if/do/break | 14:15.52 |
| Robin_Watts | tor8: yes. | 14:17.00 |
| tor8 | two nested do { do { ... } while (tok != EOF) } while (tok != EOF); | 14:17.08 |
| Robin_Watts | I haven't changed that :) | 14:17.22 |
| tor8 | it's your code ;) part of the trylater stuff I think? | 14:17.52 |
| Robin_Watts | IIRC the reason for that is to avoid repeatedly entering an fz_try. | 14:17.57 |
| tor8 | 3 extra do, break, while lines versus two more fz_throws. I think this function is already has too many do/whiles. | 14:21.26 |
| Robin_Watts | Well, we could replace the outer do/while with a goto from the end of the fz_catch | 14:21.58 |
| | Personally I prefer do/while to goto, but you can argue that the goto is 'exceptional'. | 14:22.32 |
| | likewise, the new do/while I added can be avoided with a goto. | 14:23.01 |
| tor8 | Robin_Watts: or flatten and negate the if chain, and throw there instead. reduce the nesting depth | 14:23.09 |
| | if (l == 0) throw(); etc | 14:23.25 |
| Robin_Watts | tor8: Right, but that leaves me with lots of repeated throws. | 14:23.41 |
| | ooh. | 14:23.43 |
| | I think I can replace the break with a continue | 14:23.55 |
| | and lose the innermost do/while. | 14:24.09 |
| | but that will then cause problems if we ever do add stuff at the end of the if. | 14:24.21 |
| tor8 | yes, that would work too :) | 14:24.21 |
| | s/break out/break past the throw/ and I guess I can live with the nasty do/while | 14:26.33 |
| | Robin_Watts: I wonder if you can rebase this to prior the pdf_run_xx refactoring | 14:27.22 |
| | because this is a partial revert of that commit | 14:27.34 |
| Robin_Watts | tor8: Let's find a version of this that we like, and then I'll try. | 14:27.46 |
| | ooh. | 14:28.17 |
| | switch and fallthrough might do this nicely. | 14:28.24 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=bd7dfbb303358ed6a16408a46e07c1ea1d9d0421 | 14:34.29 |
| | I like that. | 14:35.07 |
| tor8 | Robin_Watts: yeah, that looks much better. | 14:42.50 |
| Robin_Watts | I think I have the rebase done. | 14:43.43 |
| tor8 | hm, looking at that I spot one immediate difference | 14:47.18 |
| | we now treat all arrays like this, even outside of BT/ET | 14:47.36 |
| Robin_Watts | tor8: yes. | 14:47.48 |
| tor8 | which may not be a danger, but it does allow us to have embedded Tc and Tw operators in the middle of marked content or image dictionaries | 14:48.08 |
| kens | Or other operators too | 14:48.18 |
| Robin_Watts | not dictionaries. | 14:48.20 |
| | only arrays. | 14:48.27 |
| kens | MIght be intriguing to see what Acrobat does with those | 14:48.27 |
| Robin_Watts | so marked content or image dictionaries are safe. | 14:48.47 |
| kens | image diuct may contyain an array | 14:48.49 |
| Robin_Watts | but we could get [1 0.0 Tc 2 3 4 ] 5 d | 14:49.09 |
| tor8 | Robin_Watts: right. so, will we parse correctly a marked content object that is an array with embedded arrays or dicts? | 14:49.10 |
| Robin_Watts | marked content objects have to be dicts don't they? | 14:49.30 |
| tor8 | [ 0 1 2 << /Foo (bar) >> ] BMC will not work now | 14:49.31 |
| | Robin_Watts: I'm not sure :) | 14:49.38 |
| Robin_Watts | tag properties DP | 14:50.34 |
| | tag properties BDC | 14:50.42 |
| | tag is always a name | 14:50.47 |
| | properties is either an inline dict, or a name. | 14:50.54 |
| | so we're safe. | 14:50.57 |
| tor8 | right. | 14:51.23 |
| | I would still be more comfortable if we guard with in_text and call parse_array in the other cases. more robust. | 14:52.04 |
| | if (intext) { obj = parse_array() } else { in_array=1; obj=new_array() } | 14:54.14 |
| Robin_Watts | ok. | 14:54.28 |
| tor8 | of course, what we have now will work for TJ without BT/ET, so we probably should test it first | 14:55.30 |
| Robin_Watts | I've just run a test with the change before the rebase. | 14:56.06 |
| | i.e. without the special casing of in_text | 14:56.45 |
| | and it showed no changes. | 14:57.49 |
| | so I'll put the in_text special case back. | 14:57.49 |
| | So, effectively now, we only go into the in_array case, when we are in_text. | 14:58.57 |
| | Can I rename it in_text_array rather than in_array to make that plain? | 14:59.09 |
| tor8 | Robin_Watts: yes, that would be good | 15:01.49 |
| Robin_Watts | tor8: OK. commits on robin/master look good to go then. | 15:08.21 |
| | Everything from pdf_output_obj to "Move rdb..." | 15:08.54 |
| tor8 | Robin_Watts: yes. | 15:09.52 |
| Justcune | t | 15:45.37 |
| | tt | 15:45.39 |
| | http://www.google.it | 15:45.44 |
| | hey | 15:45.48 |
| ghostbot | bonjour, justcune | 15:45.48 |
| Justcune | you | 15:45.49 |
| | hello | 15:45.58 |
| ghostbot | hola, justcune | 15:45.58 |
| Justcune | hello | 15:46.03 |
| ghostbot | que tal | 15:46.03 |
| Justcune | what | 15:46.10 |
| kens | Ah, an idiot | 15:46.29 |
| Robin_Watts | tor8: ass. | 16:09.40 |
| | Looks like I broke mupdf at some point during the sequence of commits. | 16:09.56 |
| | so it's broken for 1 commit. | 16:10.07 |
| | Do we care ? | 16:10.09 |
| | Should I rebase to fix it and force push? | 16:10.23 |
| tor8 | not really. depends on marcosw and the testing regression. it's been live a few hours so I'm more worried about people having pulled during the broken window. | 16:10.48 |
| Robin_Watts | ok. I agree, let's ignore it. | 16:11.11 |
| | tor8: So, we got 3 patches offered to us over the weekend. | 16:11.36 |
| | The first cures the inability we currently have to insert a new page into an empty page tree. | 16:12.08 |
| | The second adds tweaks to the tiff functions for handling multi page tiffs. | 16:12.39 |
| | And the third adds a new document handler that copes with multi page tiffs. | 16:12.57 |
| tor8 | okay. | 16:13.28 |
| Robin_Watts | The only problems I can see: | 16:13.44 |
| tor8 | multipage tiffs, I can't remember, is that part of the baseline TIFF spec? | 16:13.54 |
| Robin_Watts | 1) he uses "unsigned" when I think we prefer "unsigned int" | 16:13.54 |
| | 2) he doesn't remove tiff handling from the muimage agent. | 16:14.14 |
| tor8 | I have been known to do the same (raw "unsigned" rather than "unsigned int") | 16:14.21 |
| Robin_Watts | oh, ok. | 16:14.34 |
| | but those are simple fixes. If we only have to do 2), even more so. | 16:15.00 |
| tor8 | if we add a separate tiff agent, I think we should remove tiff support from the muimage agent | 16:15.05 |
| Robin_Watts | Yes. | 16:15.12 |
| | I'll grab his patches and make some commits for you to look over. | 16:15.40 |
| kens | Multiple images in a single TIFF file are part of the baseline spec. | 16:16.22 |
| tor8 | kens: right. thanks. I guess I just skipped that part of the spec when implementing TIFF for XPS | 16:16.45 |
| kens | TIFF doesn't really have a concept of 'pages' but treating each image as a separate page makes reasonable sense | 16:16.47 |
| | Its hard to see what else you would do | 16:17.11 |
| tor8 | Robin_Watts: yeah, the raw "unsigned" stuff is "when in rome" ... the current load-tiff.c is full of it :) | 16:18.15 |
| madmoose | Robin_Watts: I think I used unsigned because that was what the rest of that code used. I don't prefer it | 16:19.52 |
| Robin_Watts | madmoose: Fair enough. | 16:20.05 |
| | madmoose: How did you make the patches? | 16:20.13 |
| madmoose | There's (potentially) an attribute for page number on each subim[Dage. | 16:20.59 |
| | My git-fu is weak, I just used git diff | 16:21.57 |
| Robin_Watts | madmoose: And you've sent a signed CLA to Miles, right? | 16:21.59 |
| | madmoose: That's fine. I can massage them. | 16:22.10 |
| madmoose | Robin_Watts: Yes. I even attached it on the second attempt. | 16:22.23 |
| Robin_Watts | Thanks. | 16:22.34 |
| kens | knows that feeling well | 16:22.36 |
| madmoose | Robin_Watts: The exception handling at least needs to be checked :) | 16:24.09 |
| ray_laptop | Robin_Watts: mvrhel: which do you think is better for the psdcmykog device -- have the device ignore the SeparationOrder parameter, or throw an error (which silently ignores the error due to the default Policy) ? | 16:29.50 |
| | The issue with the latter (throw an error) is that the rest of the parameter list will be ignored as well since if there is any error none of the parameters are applied. | 16:29.51 |
| | kens: your opinion welcome as well | 16:30.16 |
| | (or anyone else) | 16:30.35 |
| kens | I'd havew ith throw an error, even if the Policy ignores it. THat way people can choose to see it | 16:30.41 |
| Robin_Watts | ray_laptop: Do we have to throw the error immediately? Can't we do the rest of the put_params and then throw the error at the end ? | 16:30.59 |
| kens | Maybe the default Policy should be different | 16:31.06 |
| Robin_Watts | but I think I agree that the error should be thrown. | 16:31.27 |
| mvrhel_laptop | ray_laptop: I agree | 16:31.32 |
| ray_laptop | Robin_Watts: no, the definition requires that parameters only get applied if there are no errors on any params | 16:31.32 |
| Robin_Watts | ray_laptop: Oh, ok. | 16:31.47 |
| | Well, then I still think we should throw it. | 16:32.20 |
| ray_laptop | I'd be loathe to change the default policy. A lot of uses would probably start breaking | 16:32.47 |
| madmoose | None of the document types currently return anything but 100 (or 0) in *_recognize, so I thought that overriding muimage by returning 200 was a good use of that ability :) | 16:34.11 |
| ray_laptop | OK. throwing the error will make the psdcmykog device act more like a non-DeviceN device like tiff32nc | 16:34.11 |
| | thanks to all for the consultation | 16:34.48 |
| Robin_Watts | madmoose: Well, it's supposed to be a percentage, so it's hard to see how you can be 200% sure it's a tiff :) | 16:34.51 |
| | but if we're including this device by default, it's neater not to have the overlap IMHO. | 16:35.21 |
| madmoose | Robin_Watts: Haha, ok, that makes sense then :) | 16:35.36 |
| ray_laptop | eye dr. appt. bbiaw | 16:35.46 |
| Robin_Watts | I think the error handling in fz_load_tiff_subimage_count is redundant. | 16:37.40 |
| | as nothing in the functions that are called allocate memory. | 16:37.55 |
| | but errrors can be thrown, so let me just tweak the message. | 16:38.30 |
| madmoose | it actually doesn't do any loading either, so you might want to tweak the name too | 16:39.56 |
| mvrhel_laptop | spent the weekend reinstalling all the software on my laptop after it crashed saturday morning | 16:41.46 |
| | just a few more things to fix up.. | 16:42.02 |
| Robin_Watts | mvrhel_laptop: But you had a recent backup, right? :) | 16:42.19 |
| mvrhel_laptop | still not sure what happened but it was likely a display driver issue | 16:42.22 |
| madmoose | and I didn't know whether to name it fz_load_tiff_info_subimage or fz_load_tiff_subimage_info | 16:42.34 |
| mvrhel_laptop | Robin_Watts: sadly no. but luckily no data was lost | 16:42.37 |
| | Robin_Watts: I am going to do a big push here today to get my gsview stuff up to my repos | 16:43.02 |
| Robin_Watts | mvrhel_laptop: There, but for the grace of God, go we all. | 16:43.07 |
| mvrhel_laptop | I will probably have you start reviewing stuff soon | 16:43.17 |
| Robin_Watts | ok. | 16:43.21 |
| | madmoose: I'm struggling to think of a better name. | 16:43.33 |
| mvrhel_laptop | needless to say I was in a panic saturday morning | 16:43.39 |
| Robin_Watts | mvrhel_laptop: Yeah. My neighbour wanted to upgrade from 32bit Win 7 to 64 bit win7 on his works server machine (he runs a garage). | 16:44.40 |
| | I told him to buy a new SSD and we'd install the new version on that, as that would be safest. | 16:45.05 |
| | So he shut it down at work, brought it home... and it wouldn't reboot. | 16:45.20 |
| | we can get it into safe mode, but not into normal mode. | 16:45.49 |
| | so I spent saturday footling with that with various rescue discs. | 16:46.07 |
| kens | Hmm but that's enough to get the data off ? | 16:46.09 |
| Robin_Watts | kens: Well, the data is stuck in an SQL database, and the sql server is one of the things that safemode won't run... | 16:46.32 |
| kens | oh.... | 16:46.41 |
| Robin_Watts | but I think he's got a backup from friday night, so he's only lost saturday mornings stuff. | 16:47.09 |
| mvrhel_laptop | wow | 16:47.38 |
| | kens: got your email. I will look over this today | 16:48.02 |
| Robin_Watts | Annoyingly though he opened at 8am this morning, and can't use the server until he can get new keys for the software and reinstall the backup - and the keys won't be available until at least 9am. | 16:48.18 |
| kens | mvrhel : I'm seeing LCMS fail in cmsio.c, ReadICCMatrixRGB2XYZ | 16:48.29 |
| Robin_Watts | presumably he has it all working, cos I've not had any paniced phone calls :) | 16:48.38 |
| mvrhel_laptop | kens ok | 16:48.46 |
| kens | I'm now terminally confused, so I'll leave it to you Michael.... | 16:49.09 |
| Robin_Watts | mvrhel_laptop: I'm assuming that you've not looked at the lcms threading stuff because of all this? | 16:49.28 |
| kens | It seems to be failing to read some tags out of the ICC profile | 16:49.38 |
| mvrhel_laptop | Robin_Watts: I will def. get that done today. I feel bad for letting that languish | 16:50.01 |
| Robin_Watts | It's not critical. | 16:50.11 |
| | We have what we wanted from the work that martis done. | 16:50.22 |
| mvrhel_laptop | no but it is something that is hanging over me that I can get done quickly and then move on | 16:50.35 |
| Robin_Watts | but if we can get that too, that'll be even better. | 16:50.40 |
| | ok. Let me know if I can help with anything. | 16:50.56 |
| mvrhel_laptop | ok thank you | 16:51.00 |
| Robin_Watts | I've got to shoot out to get Helen in a bit, but will be back after that. | 16:51.08 |
| kens | Hmm, well the ICC profile I'm including now (generated via -dUseCIEColor) definitely doesn't have a rXYZ, gXYZ or bXYZ tag. | 16:52.36 |
| | So I'm probably doing somethgin wrong :-) | 16:52.50 |
| mvrhel_laptop | first task for me this morning though is to get this code cleaned up and pushed to my repos before another accident occurs | 16:58.19 |
| kens | :-) | 16:58.31 |
| tor8 | Robin_Watts: that's curious... I implemented "lightweight" functions in libjs, for functions that don't need a full variable object and closure. now we can run the fibonacci benchmark faster than spidermonkey without the JIT! that's unexpected... | 17:05.28 |
| mvrhel_laptop | brb | 17:05.34 |
| Robin_Watts | tor8: That's a nice result, but be careful... I can see you getting sucked into "ooh, if I do this, it'll be faster..." and that way madness lies :) | 17:06.31 |
| tor8 | Robin_Watts: yes. this is for a very strict subset of functions, and gives a *huge* boost | 17:06.47 |
| | not having to create a variable object and environment record (that will become garbage) for every function invocation is very low hanging fruit | 17:07.38 |
| | this is a factor 15 speed up. | 17:08.23 |
| | for the fibonacci benchmark. | 17:08.29 |
| Robin_Watts | yes, indeed, a nice result. | 17:10.27 |
| | tor8: OK, 3 more reviews on robin/master for you then. | 17:13.31 |
| kens | Night all | 17:32.10 |
| Robin_Watts | henrys_: You here? | 17:36.41 |
| | Oh, better and better. Freetype doesn't support getting kerning data from GPOS entries. | 17:39.55 |
| tor8 | Robin_Watts: yeah, that's annoying. | 17:44.40 |
| Robin_Watts | So, as a test, I just opened the same doc in 2 libre office windows. | 17:47.40 |
| | It's a doc that uses arial throughout. | 17:47.49 |
| | So I selected all, and I replaced with SwissA, the best version of the clone font that I've managed to make, by matching metrics etc. | 17:48.41 |
| | The glyphs from the clone font look horrible, due to the lack of AA in libreoffice, and the fact that they have no hinting information. | 17:49.13 |
| | but at print resolutions, that's probably not an issue. | 17:49.32 |
| | The layout appears identical though. | 17:51.22 |
| | (the one thing I can spot that's different on the first 2 pages is because I don't have a bold version of SwissA installed) | 17:51.55 |
| | LibreOffice uses freetype, I think. | 17:54.24 |
| | Maybe I'm just being lucky on this page and getting away with kerning data not mattering. | 17:55.04 |
| | Arial offers a 'kern' table as well as a GPOS table. | 17:55.22 |
| | Oh, God. .odt files are different to .docx ones. | 18:02.31 |
| | The nice things about standards is that there are so many to choose from. | 18:02.40 |
| | Well, the good news is that with proper fonts, ghostdocs is MUCH closer to matching libreoffice. | 18:16.12 |
| mvrhel_laptop | whew. ok so now all my code is on the repos. no more living on the edge for me | 18:16.18 |
| Robin_Watts | but I still have 1 line where it breaks differently. | 18:16.51 |
| mvrhel_laptop | Robin_Watts: sorry to jump in the middle of all you font fun. so do you think we will have something pretty close to matching to demo in japan | 18:17.14 |
| | s/you/your/ | 18:17.21 |
| Robin_Watts | and that off course can ripple down throughout all following pages. | 18:17.31 |
| | s/off/of/ | 18:17.32 |
| | When is the deadline for that? | 18:17.41 |
| mvrhel_laptop | we leave on the 22nd | 18:17.53 |
| | so we have 2 weeks | 18:17.57 |
| Robin_Watts | OK. | 18:17.58 |
| | Well, I could run through all the clone fonts, and apply my metric forcing program to them. | 18:18.27 |
| | Then I could build a version of ghostdocs with those built in. | 18:18.46 |
| | (or I could strip them to ef1's and then build them in to save space). | 18:18.56 |
| mvrhel_laptop | Robin_Watts: whatever you think is best. I only need to have a few documents that look good and match decently | 18:19.02 |
| Robin_Watts | That would give us something that is MUCH closer than before. | 18:19.04 |
| | OK, so it sounds like that is worth me doing anyway. | 18:19.42 |
| | I will do that tomorrow. Then we can all have a discussion about what we think the proper 'longer term' solution for this is. | 18:20.08 |
| mvrhel_laptop | Robin_Watts: sounds great. thank you | 18:20.17 |
| Robin_Watts | whether it's feasible to shoot for a perfect match or not etc. | 18:20.22 |
| mvrhel_laptop | right | 18:20.28 |
| henrys_ | Robin_Watts: sorry I was away, back now | 18:21.17 |
| Robin_Watts | henrys_: No worries. | 18:21.26 |
| | I was going to ask for some direction on this fonts stuff. | 18:21.50 |
| | but I think I know what I should do for the next day or so anyway - we can talk more about it at the meeting (or after the meeting as I fear it may be a long discussion) | 18:22.26 |
| henrys_ | Robin_Watts: just enough to get mvrhel_laptop through a demo | 18:22.43 |
| mvrhel_laptop | Robin_Watts: you still there? | 18:58.52 |
| | marcosw are you there? | 19:21.06 |
| marcosw | mvrhel_laptop: yes, I am now. | 19:41.53 |
| mvrhel_laptop | hi marcosw: during my recent windows fixup I had to reinstall firefox and lost all the cookies etc that I had including my password to the dashboard. | 19:42.44 |
| | I can not find the email that you sent me long ago with the password | 19:42.55 |
| marcosw | I'll resend it (or create a new one and send you that if I can't find it either). | 19:44.00 |
| mvrhel_laptop | ok thank you | 19:44.08 |
| marcosw | mvrhel_laptop: here it is: ******** | 19:45.19 |
| | (sorry, old joke, I've emailed it). | 19:46.17 |
| mvrhel_laptop | ok thanks! | 19:46.48 |
| marcosw | http://www.bash.org/?244321 | 19:46.55 |
| mvrhel_laptop | :) | 19:47.52 |
| Robin_Watts | marcosw: ping | 20:05.17 |
| mvrhel_laptop | Robin_Watts: ping | 20:35.42 |
| | Robin_Watts: I remember that you had sent me the patch to use to test out Marti's stuff with you changes and I remember applying the patch at one point but I can not find the patch nor do I see where I applied it. It is like I dreamt the whole thing | 20:37.57 |
| zeniko | Robin_Watts: two minor patches for review on zeniko/mupdf | 20:44.51 |
| mvrhel_laptop | bbiaw | 20:51.54 |
| Robin_Watts | mvrhel_laptop: For the logs: It's on robin/lcms2_thread | 20:58.29 |
| | zeniko: For the logs: will look tomorrow. | 20:58.45 |
| mvrhel_laptop | thanks robin | 21:54.17 |
| marcosw | Miles' office is going to experience a planned power outage tonight and again tomorrow night. The ups should keep bugzilla and the cable modem up during that time but I don't know about the other internet infrastructure so there may be some downtime. The cluster nodes are not on battery back-up so we'll be running with a reduced cluster capacity during the outage. it will be in the evening PST so it shouldn't be an issue (unles | 22:23.17 |
| | Forward 1 day (to 2014/02/11)>>> | |
IRC Logs