| | <<<Back 1 day (to 2015/04/05) | 20150406 |
| Robin_Watts | Morning paulgardiner | 09:18.08 |
| | I wonder what I should do today... | 09:18.43 |
| | I think my MuPDF fiddling is at an end (until Tor appears at least) | 09:19.00 |
| | Actually, maybe I should look at that customer thing with hebrew.pdf | 09:20.03 |
| | tor8! | 10:08.12 |
| | Happy Easter. | 10:08.15 |
| tor8 | morning Robin_Watts | 10:08.15 |
| | thanks. | 10:08.18 |
| Robin_Watts | are you working today? | 10:08.26 |
| tor8 | today is also a bank holiday here, but I figured I'd pop in and review your stuff at least | 10:08.33 |
| Robin_Watts | Thanks. | 10:08.39 |
| | It's a bank holiday here too, but I'm working regardless. | 10:08.56 |
| tor8 | Robin_Watts: if you're thinking of tackling the customer issues, I think the japanese.pdf one will be easier | 10:09.12 |
| Robin_Watts | Just going to look into why Jung's.... yeah. that's the file I have open. | 10:09.21 |
| tor8 | it's got font bboxes gone wrong | 10:09.23 |
| Robin_Watts | the hebrew.pdf one seems fine actually. | 10:09.39 |
| kens | is working today also | 10:09.42 |
| tor8 | we don't use individual glyph bboxes for fonts that have > N glyphs | 10:09.43 |
| | I couldn't see anything wrong with the hebrew file, so I suspect the error is in their code | 10:09.59 |
| Robin_Watts | His complaint with that is "when sarching it returns 42 copies" | 10:10.04 |
| | I bet he's misusing a fragment of code from gsview, based on what he says later. | 10:10.22 |
| tor8 | I got a snippet of his code, I'm not sure if he CC:d you on that as well | 10:10.24 |
| Robin_Watts | tor8: yeah, he lifted it from gsview I think. | 10:10.40 |
| tor8 | it looks pretty straight forward, but who knows what the C++ code behind the scenes does | 10:10.45 |
| Robin_Watts | the new version of gsview gets it right. | 10:11.31 |
| | so it must be something he's doing wrong. | 10:11.39 |
| | tor8: one idea for the glyph bbox stuff.... | 10:13.17 |
| | instead of allocating a single array of bboxes for the glyphs, we could have a sparse representation. | 10:13.39 |
| | Maybe break it down into 256 char chunks. | 10:13.49 |
| | Then populate them lazily? | 10:14.01 |
| | Would still be constant time for access (after the first access in a block) | 10:14.26 |
| tor8 | Robin_Watts: it's a possibility | 10:14.44 |
| Robin_Watts | I might give that a spin. | 10:14.58 |
| tor8 | but all the font descriptors in the japanese.pdf file have reasonable FontBBox entries | 10:15.58 |
| Robin_Watts | ah, we already populate lazily. | 10:16.15 |
| tor8 | which should be used as fallbacks | 10:16.18 |
| Robin_Watts | OK, so ensure the fallback works, | 10:16.28 |
| tor8 | yes, it's just the memory use of adding a glyph bbox table for all the glyphs in a font that's bothersome | 10:17.01 |
| | the table is indexed on glyph index, so it's already compact | 10:17.10 |
| | no holes depending on the character encoding | 10:17.20 |
| Robin_Watts | Is the problem that we use the advance in place of the width or something | 10:17.48 |
| | ? | 10:17.50 |
| tor8 | oh, yes. that could be it! | 10:18.20 |
| | we might be using the horizontal advance in the text extraction place where we set the glyph bboxes | 10:18.38 |
| Robin_Watts | Ah, we're using FT_Get_Advance | 10:18.49 |
| | TODO: freetype returns broken vertical metrics | 10:19.05 |
| tor8 | that whole chunk should be using our fz_font based metrics code... :/ | 10:20.05 |
| Robin_Watts | tor8: Well, that should be fixable. | 10:20.57 |
| | I will play with it. | 10:21.05 |
| tor8 | fz_advance_glyph is the call that should be used | 10:21.21 |
| | and that should be tweaked to deal with wmode | 10:21.32 |
| | or just fz_advance_glyph_vertical | 10:21.43 |
| Robin_Watts | hmm. That ends up calling FT_Get_Advance too. | 10:22.02 |
| | Shouldn't we just be calling fz_bound_glyph ? | 10:22.35 |
| | The structured text stuff is supposed to return the bboxes of the glyphs, right? | 10:23.42 |
| | Or maybe it should return both. | 10:23.50 |
| tor8 | the section with 'TODO: broken vertical metrics' just updates the expected position and compares with the actual position of the next glyph to detect spaces | 10:24.54 |
| | and then passes that on to fz_add_text_char which expects to use the advance as part of the real bbox | 10:25.25 |
| | if we use the actual glyph bbox, the selection outline for text will look like a skyline | 10:25.44 |
| | so we fudge and use the line height + advance widths to make the bboxes | 10:25.59 |
| | the actual bboxes are just for glyph rendering | 10:26.12 |
| | and we use the line height + advance width as the selection area | 10:26.30 |
| | but that code has never thought about the vertical wmode case, I expect | 10:26.47 |
| Robin_Watts | tor8: yeah, the fz_text_char_s structure has a single 'point' in it. | 10:27.34 |
| | so at best it can describe (when combined with the height/transform information in the span) one edge of the glyph. | 10:28.09 |
| | So... fix that to use the 'proper' advance according to wmode. | 10:28.43 |
| | If people want the real bbox of an extracted glyph they should call bound_glyph and transform it as appropriate. | 10:29.19 |
| | I will play a bit. | 10:29.42 |
| tor8 | ah, fz_text_char_bbox is the function that does the guessing | 10:30.30 |
| | and it looks at the point-to-point delta for the fz_text_chars (and the span 'end' point for the last char) | 10:31.02 |
| Robin_Watts | yeah. | 10:31.35 |
| | fz_text_char_bbox_outer ? | 10:31.50 |
| | ahem, let me try that again. | 10:32.05 |
| tor8 | so we should take the fz_text_span wmode into account there | 10:32.23 |
| Robin_Watts | Should we maybe have an fz_text_char_bbox_non_advance (or something better named) that gives a bbox based on the char bbox rather than the advance? | 10:32.40 |
| tor8 | and just flip the ascender/descender and x/y's | 10:32.50 |
| | I'd expect we want the same non-skyline selection behaviour for vertical text as well | 10:33.15 |
| | fz_text_char_selection_box and fz_text_char_bitmap_box? | 10:33.42 |
| | if we want two separate style bboxes | 10:33.52 |
| Robin_Watts | tor8: I'm not denying the non-skyline thing. I'm wondering if there should be a safe method... yeah, exactly. | 10:33.58 |
| | OK, let me try and fix the existing use case first. | 10:34.12 |
| tor8 | the mutool pages command is partially covered by mutool info | 10:34.36 |
| | but the new command is more streamline | 10:34.42 |
| | d | 10:34.44 |
| Robin_Watts | tor8: mutool info is... bonkers. | 10:34.53 |
| | It only tells you the first page on which each thing appears. | 10:35.10 |
| tor8 | yeah, it's not been maintained for several years since sebras first wrote it | 10:35.48 |
| Robin_Watts | so if you have a 1300 page file which alternates between each of 2 different page sizes, it's useless for finding out which page is actually which (unless you call it 1300 times) | 10:35.56 |
| | I'd be tempted to extend mutool pages to also list fonts etc on each page, probably with the same set of command line flags. | 10:36.30 |
| tor8 | most commits LGTM; the big red 'X' and the two dropout commits I'll want to review and discuss in more depth but the rest looks good to go | 10:36.44 |
| Robin_Watts | but what I have there is sufficient for the customers needs. | 10:36.49 |
| | tor8: cool, ta. | 10:36.53 |
| tor8 | just list the fonts and images by object number, not the same in-depth subtype analysis that mutool info tries, I hope :) | 10:37.33 |
| | for easier analysis with mutool show later | 10:37.46 |
| | I tend to use 'mutool show p' to get the page object number, then find the /Resources, etc, etc | 10:38.09 |
| | having a simple mutool pages -R 5 to list the resource dictionaries on page 5 would be neat | 10:38.37 |
| Robin_Watts | tor8: Yeah, I'd just have: <fonts><font name="x" obj="y">...</fonts> for each page or something. | 10:38.50 |
| tor8 | and mutool pages -C 5 to dump the content stream :) | 10:39.00 |
| | yeah, something like that | 10:39.28 |
| Robin_Watts | dumping the content stream in xmlish form would require escaping :( | 10:39.33 |
| tor8 | oh yeah, mutool pages dumps in xml syntax | 10:39.35 |
| | xml-escaping is easy though | 10:40.01 |
| Robin_Watts | tor8: but the user wouldn't really want to have to unescape things like inline binary image data | 10:41.19 |
| | probably better to give the object number in the xml then have a separate command to dump the contents. | 10:41.38 |
| tor8 | Robin_Watts: fair enough | 10:41.48 |
| Robin_Watts | Or even just have mutool contents. | 10:41.52 |
| | but this can be driven by interest in the command :) | 10:42.00 |
| tor8 | mutool show -b on the object number | 10:42.02 |
| Robin_Watts | tor8: right. | 10:42.12 |
| tor8 | well, mutool show is for human consumption (modulo the -b option) | 10:42.22 |
| | and mutool pages sounds like it's for machine consumption due to its xml-ness | 10:42.36 |
| Robin_Watts | it's simplistic enough xml (for I am a simplistic enough human) that humans can read it too. | 10:43.15 |
| tor8 | like all our other xml :) | 10:43.32 |
| | the trace device and stext output | 10:43.56 |
| Robin_Watts | tor8: My current bmpcmp output is with all the antidropout stuff in, with a threshold of 33. | 10:45.55 |
| | 108 is the interesting one :) | 10:46.48 |
| tor8 | interesting color change! | 10:47.34 |
| Robin_Watts | and 388 (the first one on the last page) | 10:48.31 |
| | I think those paths are made up of lots of individual thing horizontal lines. | 10:48.46 |
| | s/thing/thin/ | 10:48.58 |
| tor8 | I still think it could be done as part of the edge list (for horizontal features) and the scan converter (for vertical features) | 10:49.30 |
| Robin_Watts | tor8: I stared at pencil scribbles for a very long time over this :) | 10:50.17 |
| tor8 | which to me would feel more robust than tweaking special cases during stroking | 10:50.20 |
| Robin_Watts | specifically trying to do it in the scan converter. | 10:51.20 |
| | Crap. 724 looks wrong. | 10:51.37 |
| | The attractions of this method are that a) (I hope) it's safe, and b) it shouldn't affect speed. | 10:53.29 |
| tor8 | yeah, it looks reasonable at a second glance | 10:56.00 |
| | it's clear what you're trying to accomplish and it should work reasonably well for the special case of pure horiz/vertical features | 10:56.32 |
| | which I guess is good enough for now | 10:56.38 |
| Robin_Watts | Thanks. | 10:56.50 |
| tor8 | implementing another fill rule that any part of a pixel touched is painted is more work... | 10:56.58 |
| | so if you can figure out the issue with 724 I think we can get this in | 10:57.35 |
| Robin_Watts | tor8: yeah. | 10:58.35 |
| | just doing an android build now to test whether the bboxes for the japanese stuff are now right. | 10:59.02 |
| | Did you have anything to add to CHANGES ? | 10:59.53 |
| | I'm thinking your html stuff is underreported there. | 11:00.04 |
| tor8 | EPUB as an input format needs mention | 11:00.57 |
| Robin_Watts | That should be there. | 11:01.14 |
| tor8 | and you glossed over all the major API cleanups with the fz_context being added everywhere | 11:01.16 |
| | with a simple 'Removal of bound contexts.' :) | 11:02.00 |
| | I think the EPUB and memory usage optimizations are the main user visible features that have gone in | 11:03.06 |
| | can't really think of anything else significant, but I'm sure I'll remember something the minute I upload the release :) | 11:03.50 |
| Robin_Watts | tor8: Feel free to reword what I have, probably easiest. | 11:04.00 |
| | Unless you want to disappear again and actually have a holiday :) | 11:04.31 |
| | ok, android app is clearly not happy selecting vertical text. | 11:04.52 |
| tor8 | * New HTML layout engine and (DRM-free) EPUB viewer. | 11:05.02 |
| Robin_Watts | but the bboxes are more believable now. | 11:05.04 |
| tor8 | it's a beautiful day, so I might disappear for a couple of hours. I'll leave the window open and check in occasionally. | 11:05.45 |
| Robin_Watts | tor8: ta. have a good one! | 11:06.07 |
| | tor8: I fixed that problem with fts_15_1516.pdf | 13:57.25 |
| | I was managing to lose the implicit close caused the the fz_move at the start of a rect. | 13:57.53 |
| | With that fixed, all good. | 13:57.57 |
| | kens, chrisl: There is a note in the MuPDF source saying that freetype produces broken vertical metrics. | 14:13.25 |
| | That dates from 2011 though. | 14:13.32 |
| | I don't suppose anyone is aware of this having been fixed? | 14:13.42 |
| kens | I'm reasonably sure we don't use them | 14:13.43 |
| | We would use the advance width (and height) but that's all I think | 14:14.27 |
| | pdfwrite would probably use more, but I don't recall any problems | 14:14.39 |
| Robin_Watts | It's the advance width for vertical motion that I'm interested in. | 14:14.50 |
| kens | If FreeTtype is producing incorrect metrics it should probably be reported anywa | 14:14.59 |
| | Robin_Watts : if the advance for vertical text is incorrect I'd expect us to get it wrong too, do you have an example ? | 14:15.24 |
| Robin_Watts | kens: No. My sole knowledge of this topic comes from looking at this comment :) | 14:15.55 |
| kens | Hmm, hard to say any more without szeeing a concrete instance | 14:16.20 |
| | If FT was genuinely producing an incrrect value I would expect GS to get the wrong asnwer, not least when using a TrueType font as a replacement for a CIDFont. | 14:16.57 |
| | The only reports I've seen of that in GS correspond to using a horinzotal font as a replacement when doing vertical writing, which I regard as 'tough' | 14:17.45 |
| chrisl | Yeh, gs will only use the Freetype metrics in certain cases, so we may not see the problem. Not least because in PDF you pretty much ignore stuff like advance widths from the font | 14:19.56 |
| Robin_Watts | Yeah, I should be using the advance widths from the PDF. | 14:28.19 |
| | and I see how the main bit of the code does that. | 14:28.27 |
| kens | THey always take precedence | 14:28.34 |
| Robin_Watts | yeah. | 14:28.39 |
| | That may not be quite as trivial as I'd like though, as I'm working at the fz_ level, and the advance stuff is at the pdf_ level... will fiddle. | 14:29.15 |
| tor8 | Robin_Watts: the pdf level metrics are fed down to the fz level (to allow for width adjusting substitute fonts) | 14:30.34 |
| Robin_Watts | tor8: The widths are in the fz_font. | 14:31.18 |
| tor8 | the width_count/width_table used in fz_advance_ft_glyph | 14:31.19 |
| | is seeded with the pdf /Widths array | 14:31.28 |
| Robin_Watts | but in the vertical motion case we need Widths2, right? | 14:31.43 |
| chrisl | W2 and DW2 IIRC | 14:32.00 |
| Robin_Watts | The layout code uses vmtx and hmtx | 14:32.12 |
| tor8 | yeah. substitute fonts in vertical mode are unadjusted. | 14:32.16 |
| Robin_Watts | chrisl: yeah, sounds right. | 14:32.21 |
| tor8 | which is usually not a problem, since most CJK fonts are the equivalent of monospaced | 14:32.37 |
| Robin_Watts | tor8: "are unadjusted in mupdf" or "are unadjusted in all of pdf" ? | 14:32.51 |
| tor8 | we use the vertical pdf metrics for layout, but we don't hack the rendering to adjust for differences between pdf metrics and (substituted) font metrics | 14:33.34 |
| | like we do with horizontal mode rendering | 14:33.43 |
| Robin_Watts | I don't follow what you mean by "hack the rendering" ? | 14:34.01 |
| tor8 | when rendering a substitute font (in horizontal mode) | 14:34.18 |
| | we compare the PDF /Widths with the FT_Get_Advance | 14:34.27 |
| | and scale horizontally to match up the FT_Get_Advance with /Widths | 14:34.54 |
| Robin_Watts | ah. | 14:35.15 |
| tor8 | we get wonky text, but at least it doesn't overlap and have odd spacing | 14:35.17 |
| | this is the reason we have width_table in the fz_font | 14:35.57 |
| | primary* | 14:36.08 |
| | a secondary benefit is that we can use it for fz_advance_glyph in other places (like the HTML layout engine) | 14:36.36 |
| Robin_Watts | I think I want to put the vertical widths into the fz_font as well. | 14:36.49 |
| tor8 | there are places that should call fz_advance_glyph but don't yet since it's a relatively new introced function | 14:36.57 |
| | introduced | 14:37.03 |
| | yeah, I would not oppose that | 14:37.08 |
| | considering that a fz_font is either H or V mode, you should be able to reuse the same width_table? | 14:37.55 |
| | or add a second origin_table to go along with it | 14:38.14 |
| chrisl | You might want to just copy the form of the W2 array from PDF, otherwise you could end up taking a *lot* of space...... | 14:38.21 |
| Robin_Watts | In pdf, we have hmtx and vmtx, which look to be a compressed set of widths. | 14:39.15 |
| tor8 | chrisl: we only use the width_table on substitute, non-CJK fonts | 14:39.16 |
| | so the whole data structure might need to be 'optimized' if we want to start using it for CJK | 14:39.42 |
| kens | CJK fonts usually only have DW or DW2 entires, but it *is* possible ot have a full set. | 14:39.58 |
| tor8 | Robin_Watts: I'd start by adding the vertical metric function call, using the freetype metrics | 14:40.14 |
| | and then we can see about feeding down the PDF metrics to the fz_font | 14:40.26 |
| chrisl | tor8: if Robin's interested in vertical metrics, he's probably looking at CJK...... | 14:40.32 |
| Robin_Watts | I wonder if the fz_font should (instead of the widths table) have a function to look up an advance width. | 14:40.33 |
| | the pdf side of things can implement that by looking in the vmtx/hmtx as appropriate. | 14:41.03 |
| | and we can reference count those structures. | 14:41.12 |
| | tor8: I don't think we should be using the vertical metric function call at all. | 14:44.55 |
| | Certainly we never use it when we layout. | 14:45.01 |
| henrys | a few errands this morning be back in a bit. | 15:09.32 |
| Robin_Watts | henrys: Any word on where the next meeting is? | 15:10.31 |
| henrys | Robin_Watts: nope haven't heard | 15:26.15 |
| Robin_Watts | would be nice to know soon, otherwise the Euros are all going to be scrabbling for the last seats. | 15:27.02 |
| henrys | Robin_Watts: okay I'll ping him to send out the email | 15:27.23 |
| Robin_Watts | Thanks. | 15:27.30 |
| kens | Yes, I asked last Tuesday but I htink Henry missed the question, was going to ask again tomorrow | 15:27.35 |
| Robin_Watts | kens: Yes, I saw the question, but didn't see a reply. | 15:28.02 |
| kens | Yeah, that's why I was going to ask again :-) | 15:28.16 |
| Robin_Watts | OK, so next meeting at SFO. | 16:42.26 |
| chrisl | Yeh, flights are already quite busy, it seems..... | 16:43.10 |
| Robin_Watts | There are 2 options on the way out/back. | 16:43.23 |
| | the later flight out is cheaper. | 16:43.33 |
| chrisl | But gets in at 7pm..... | 16:44.13 |
| Robin_Watts | It's a trade off - less of an early start, but up late when we get there. | 16:45.00 |
| | What do you reckon? | 16:45.03 |
| chrisl | I'd rather the earlier flight, but it's not a huge preference, to be honest | 16:45.31 |
| Robin_Watts | Plus I figure we've got to pay an extra 50 quid if we want to be able to book seats. | 16:45.34 |
| chrisl | And we'll have to entertain ourselves all Sunday..... | 16:47.37 |
| paulgardiner | zeR5tWek | 16:47.45 |
| chrisl | Password change alert ;-) | 16:47.58 |
| paulgardiner | :-#9 | 16:48.23 |
| Robin_Watts | chrisl: We always have to entertain ourselves all sunday. | 16:48.49 |
| chrisl | We've had meetings Saturday/Sunday before.... | 16:49.38 |
| Robin_Watts | sometimes, yes. | 16:50.14 |
| chrisl | Anyway, my slight issue with the later outbound flight is eating that evening could be a problem | 16:50.24 |
| Robin_Watts | I would probably prefer the earlier flight, TBH. | 16:50.41 |
| | cos arriving/running/showering/eating works well the way we do it normally. | 16:51.00 |
| | landing at 7 means we won't be at the hotel til 8. | 16:51.18 |
| chrisl | I would say *at least* 8 | 16:51.39 |
| Robin_Watts | yeah. | 16:51.45 |
| | So, shall we take the executive decision that we're flying on the earlier flight? | 16:52.00 |
| chrisl | That would be better for me.... if Miles wants cheaper flights he should tell us earlier :-) | 16:52.25 |
| Robin_Watts | So cheapest flights that way are 856. | 16:52.45 |
| chrisl | Possibly check with kens before we book? | 16:53.06 |
| | Robin_Watts: I assume you're looking at virgin? | 16:54.42 |
| Robin_Watts | I am. | 16:54.47 |
| chrisl | VS019 out, and VS020 back | 16:55.25 |
| Robin_Watts | Yes. With miles I can get PE both ways for 150 quid extra. | 16:56.26 |
| chrisl | Only four seats in PE for the outbound leg | 16:56.48 |
| Robin_Watts | just waiting for paul to ring me back. | 16:58.24 |
| | paul has rung back. | 17:04.32 |
| | I'm going for those flights. | 17:04.38 |
| chrisl | Hopefully, kens will check the logs later on..... | 17:06.28 |
| | I hate the VA website..... | 17:07.55 |
| mvrhel_laptop | wow it is cheap for me to fly to sfo. 177 round trip... | 17:08.16 |
| | have not seen those prices in a while | 17:08.27 |
| Robin_Watts | chrisl: Interesting. | 17:09.55 |
| | With PE you can book your seats up front. | 17:10.07 |
| | for no charge, wheras it's at least 25 quid each way with just economy. | 17:10.24 |
| chrisl | I'm running out of time - and now the stupid site doesn't believe my birthday!! | 17:10.59 |
| | Robin_Watts: are the aisle seats in PE still free? | 17:12.17 |
| Robin_Watts | yes. | 17:12.22 |
| chrisl | Ah, both ways? | 17:12.29 |
| Robin_Watts | I have a window exit seat on the return flight. | 17:12.35 |
| | sorry, an aisle exit. | 17:13.31 |
| chrisl | Okay, I am out of time..... | 17:14.48 |
| mvrhel_laptop | ok. I finally have the thumb progress bar going and the pages viewable at the same time | 17:59.52 |
| | whew, took the whole weekend thinking about how best to do this. | 18:00.24 |
| | now on to some easier items on the list | 18:01.15 |
| Robin_Watts | mvrhel_laptop: Excellent. How did you do it in the end ? | 18:01.22 |
| mvrhel_laptop | Robin_Watts: the way we finally discussed. I redid the thumb rendering thread as a standard thread and not as a background thread. also, I slightly delayed the point where the binding between the ui and the structure that has the rendered bitmaps is established. there is no need to do it until the first couple pages have rendered. | 18:03.18 |
| | I render the first couple at full res | 18:03.27 |
| Robin_Watts | Ok. Nice. | 18:03.44 |
| mvrhel_laptop | now I am going to fix some easier things you pointed out | 18:04.10 |
| | hope you had a good Easter | 18:04.35 |
| Robin_Watts | mvrhel_laptop: Just had a quiet weekend at home. Was great. | 18:05.13 |
| mvrhel_laptop | yes the same here | 18:05.19 |
| Robin_Watts | Have you tried selecting vertical text? | 18:14.50 |
| mvrhel_laptop | Robin_Watts: oh god no | 18:15.00 |
| | hehe | 18:15.02 |
| Robin_Watts | I'm just fixing the text extraction stuff now to cope with that. | 18:15.09 |
| mvrhel_laptop | I suspect that will fail spectacularly | 18:15.22 |
| | not what you have done | 18:15.28 |
| | i mean any attempt to do so in gsview | 18:15.34 |
| Robin_Watts | "oh god no". That sounds so much like something I'd say :) | 18:15.38 |
| mvrhel_laptop | Robin_Watts: when you have a set up in mupdf to signify that the text is vertical, then I can look at making use of it | 18:17.15 |
| Robin_Watts | mvrhel_laptop: If the style has wmode = 1, it's vertical. | 18:17.32 |
| mvrhel_laptop | I need to fix that silly bug you found in the horizontal text first. | 18:17.38 |
| | Robin_Watts: ok. I will add that to the list to look into | 18:18.06 |
| | I am going to be out for a bit this afternoon. there is a developer who is doing some building of houses relatively close to us. need to make sure the city has not crazy plan of opening up our cul-de-sac to connect to it. | 18:18.57 |
| | s/not/no/ | 18:19.02 |
| Robin_Watts | urgh. Town planning :( | 18:20.04 |
| | They have gone house building mad in the UK. | 18:20.39 |
| | We have 2 estates being built here. One is on a brownfield site, for 35 homes. | 18:21.36 |
| | Another is on a greenfield site, with 70 homes. | 18:21.48 |
| | They applied for planning permission for the greenfield site in 1997, and it was turned down for a whole host of reasons. | 18:22.21 |
| henrys | why are getting duplicate path segments with -ZP. I hope we aren't actually storing this stuff, I fear we might be since the segments have different addresses. Postscript is on line 1 and the rest is gs with path debugging. http://pastebin.com/Sy4eQPZz | 18:22.24 |
| Robin_Watts | (bad access, liable to flood, not enough water pressure, not enough electricity supply, school and doctors at the limits etc). | 18:22.50 |
| | They applied again in 2013 without changing anything, and were turned down. | 18:23.07 |
| | They appealed and lost the appeal. | 18:23.18 |
| | Then the Minister of state said "oh go on then", and overruled everyone. | 18:23.36 |
| | So the village is up in arms about it, but there is nothing we can do. | 18:23.53 |
| | Paul lives in woodstock. Currently about 1500 houses. | 18:24.12 |
| | They've just announced that they are going to build *another* 1500 houses. | 18:24.22 |
| mvrhel_laptop | wow | 18:28.59 |
| Robin_Watts | This is on top of other major developments in Bloxham, Banbury, and a whole new "garden city" being built at Bicester, all within 30 minutes drive. | 18:29.44 |
| | tor8: Various commits on robin/text_fiddling | 18:30.46 |
| kens | Robin_Watts : you there ? | 19:30.08 |
| Robin_Watts | I am. | 19:30.15 |
| kens | Did you reserve seats for hte flight ? Ort are you hoping to pick up seats online when checxking ion? | 19:30.35 |
| Robin_Watts | kens: I upgraded with PE. | 19:31.07 |
| kens | Ah fair enough | 19:31.16 |
| Robin_Watts | With PE you get seat reservations for free. | 19:31.18 |
| | so I have them reserved. | 19:31.24 |
| kens | How much was hte upgrade ? | 19:31.24 |
| Robin_Watts | 150 quid + 7000 miles | 19:31.32 |
| kens | For teh round trip ? COs I'll take that if so :-) | 19:31.50 |
| Robin_Watts | yes. | 19:31.55 |
| kens | Cool, I'll go book now, thanks | 19:32.03 |
| Robin_Watts | 856 vs 1008 | 19:32.04 |
| kens | Well worth it | 19:32.08 |
| Robin_Watts | yeah. | 19:32.15 |
| chrisl_away | Robin_Watts, kens: can you check if there are still aisle seats in PE for the outward flight, please? If there are I'll upgrade...... | 19:35.51 |
| kens | I'm just doign miune now, gimme a moent | 19:36.02 |
| Robin_Watts | chrisl_away: I can't, I don't think. | 19:36.05 |
| | There were several when I looked. | 19:36.19 |
| | (like at least 8) | 19:36.31 |
| chrisl_away | On the booking it said only four seats left - b*stards! | 19:36.42 |
| kens | Not Bum, need to restart, the email verification failed. | 19:39.35 |
| | credit card verification I mean | 19:39.42 |
| chrisl_away | It refused to accept my birthday earlier..... | 19:40.04 |
| kens | Hmm, it says 2 seats left at the moment, that's not ideal | 19:40.48 |
| | chrisl there are still several aisle seats in each direction | 19:49.14 |
| chrisl_away | Cool, thanks. I'm already PE return, so I'll grab the outward one now.... | 19:49.48 |
| kens | Not vast numbers, but at least 3 or 4 left | 19:50.04 |
| chrisl_away | So, I wonder why it was wittering on about very few seats being left in PE earlier on | 19:50.20 |
| kens | It told me there were 2, but there are more aisle seats than that..... | 19:50.43 |
| | Just lying I guess | 19:50.47 |
| chrisl_away | Huh, and now it's removed the option for me to upgrade :-( | 19:51.03 |
| kens | FOr reference I;m in 34D out and 33D back | 19:51.34 |
| chrisl_away | Hmm, not paying 246ukp for a one way PE upgrade..... | 19:53.23 |
| kens | Crikey, no, did you check miles+money ? | 19:53.41 |
| Robin_Watts | miles+money was what I used. | 19:54.46 |
| chrisl_away | Yeh, that's how I did the original booking, with economy out and PE back. But it was listing a PE upgrade outward for 77ukp, until your booking went through, and now it's 246ukp! | 19:54.50 |
| kens | Ouch! | 19:55.19 |
| | I guess maybe I tipped them over a price point | 19:55.29 |
| Robin_Watts | The 'Only x more seats left' thing is a standard lie. | 19:55.36 |
| | I think it means "Only x more seats left at this price" | 19:55.48 |
| chrisl_away | There's no "upgrade with miles" option | 19:55.51 |
| Robin_Watts | chrisl_away: Try phoning them and explaining the situation. | 19:56.05 |
| | The people on the phone will be more adept at working the website :) | 19:56.18 |
| chrisl_away | I'm not too fussed, PE on the return is the important one | 19:56.25 |
| | And now I shall fade back into the night..... trying not to think about doing another release :-( | 19:58.12 |
| Robin_Watts | hehe. Maybe MuPDF will beat you this time :) | 19:59.06 |
| kens | OK thanks for the hint Robin_Watts heading off again now | 20:06.02 |
| rayjj | can't believe some jack*ss thinks we will care about his hand constructed sample file performing pdfwrite slowly compared to Distiller (maybe) using 8.71. I beat kens to closing this bug | 23:29.11 |
| | BTW, 8.71 was a bit faster on my laptop doing that conversion than 9.16, but Adobe was no where near as quick as claimed by the printout. The printout showed a few msec, but the stopwatch time was > 10 sec | 23:29.14 |
| Robin_Watts | rayjj: Did you see the Twiki links I posted the other day? | 23:30.17 |
| | as a start to the 'guide for how to embed gs/mupdf'. | 23:30.52 |
| rayjj | Robin_Watts: I haven't gotten around to looking at it, but I did see the IRC post. Sorry, but I've been wrapped around the axle with fixing gs transparency+transfer functions | 23:33.33 |
| Robin_Watts | rayjj: np. | 23:33.42 |
| rayjj | mupdf ignores transparency. I think I see why. | 23:34.25 |
| | At least when I've finished fixing gs, I might have enough understanding to fix mupdf the correct way | 23:34.54 |
| | The inconsistency in gs with when transfer functions are applied and when not is somewhat arbitrary | 23:35.37 |
| | BTW: s/mupdf ignores transparency/mupdf ignores transfer functions/ | 23:35.54 |
| Robin_Watts | rayjj: MuPDF ignores transfer functions entirely :) | 23:37.42 |
| | I want to completely rewrite MuPDFs transparency handling. | 23:38.34 |
| | Forward 1 day (to 2015/04/07)>>> | |
IRC Logs