| | <<<Back 1 day (to 2014/02/12) | 2014/02/13 |
| henrys | is sure his macbook is forever lost - complete failure and burning wire smell never goes well. | 05:54.48 |
| norbertj | anyone here on xps? | 08:31.41 |
| kens | In what sense norbertj ? | 08:31.55 |
| norbertj | kens: in my quest on memoryleaks I think in xpszip.c xps_read_adn_process_page_part(), if xps_parse_fixed_page() returns true, should then the xps_free_part(ctx, part) be called also (to free-up the part), before returning? | 08:33.20 |
| kens | Oh I think you need tor8 for that, since its the XPS interpreter. I don't know enough about it to help | 08:33.48 |
| norbertj | when will he be around? | 08:34.16 |
| kens | Probably in 2 hours or so, but he will read the logs (or I will tell him to ;-) | 08:34.34 |
| norbertj | ok thanks, | 08:34.44 |
| | B.t.w. you still have dry feet? | 08:35.03 |
| kens | Yes, we lie on a hill :-) | 08:35.12 |
| norbertj | I kind of feel with the unlucky ones. In 1990 I almost got wet feet myself. The water was just 50 cm away from my garden (5 cm in height). | 08:36.41 |
| | 1993 I mean. | 08:36.59 |
| kens | That's too close for comfort! | 08:37.00 |
| | As robin commented on IRC last night, its pretty much people who insist on living in flood plains here who have the problem, though the coastal storms are bad this year as well. | 08:37.43 |
| norbertj | Yeah, so I called to meteo/watermanagement , and they expected no more rising of the Maas/Meuse | 08:37.47 |
| | So for TOR, in xpszip.c: whenever a function does a return gs_rethrow(), should it not first do a cleanup, like xps_free_part? | 08:40.00 |
| tor8 | hi norbertj | 10:40.29 |
| | norbertj: it certainly looks like we're leaking the part in that code and other similar code in more places in xpszip.c | 10:44.43 |
| | chrisl: ping. | 11:00.45 |
| chrisl | to8: poing | 11:01.57 |
| | tor8: I'll be back in ~10 mins - just say what you need, I'll read it then | 11:06.04 |
| tor8 | chrisl: just wanted to know how you run skype... the 64-bit linux version seems to have dropped off the face of the earth | 11:08.53 |
| kens | Can't you just use the 32-bit version ? | 11:09.53 |
| tor8 | kens: only if I install multi-arch support, and that's a nightmare | 11:10.33 |
| kens | Hmm, well I can't help :-) | 11:10.48 |
| | As far as I can see there isn't a 64-bit version | 11:10.59 |
| tor8 | it might be easier to run it in a winxp virtualbox | 11:11.06 |
| kens | That might work | 11:11.11 |
| tor8 | kens: yeah. there used to be one, but I think they stopped updating it and now it's gone completely | 11:11.29 |
| kens | Well, I guess they only support Windows now ;-) | 11:11.43 |
| tor8 | kens: the mac version of skype has always been terrible | 11:13.23 |
| kens | Looking around the sites it seems like they *really* only support 32-bit on pretty much anything. The dependencies make it look difficult to try anything else too. | 11:14.05 |
| | THere are instructions for Debian 64-bit | 11:14.54 |
| | Fedora says use 32-bit basically | 11:15.01 |
| tor8 | kens: yeah, it might be that even the 64-bit versions are just 32-bit with dependencies on multi-arch stuff | 11:15.25 |
| | it used to be you could have some libia32 compatibility layer and run 32-bit stuff but all the linux distros are now using full multi-arch and that's not really mature code :( | 11:16.07 |
| kens | It more or less looks that way, the only one that even pretends to be 64-bit seems to be ebian, and from what some places say I don't think I would trust that either | 11:16.08 |
| paulgardiner | Robin_Watts: Bad news. 3 of the 4 docx files I was using for testing fail to open with the new GhostDocs app. | 11:19.47 |
| Robin_Watts | balls. | 11:20.00 |
| | Can you point me at them please? | 11:20.08 |
| | tor8: The mac version of skype has always worked for me. | 11:20.56 |
| paulgardiner | They are attached to an email from Marcos dated 22nd Jan at 19:45 | 11:21.03 |
| chrisl | tor8: I had to install the 32 bit skype. | 11:21.37 |
| paulgardiner | An email to tech I should have mentioned. | 11:23.16 |
| tor8 | chrisl: okay. thanks. I'm looking to see if I can get it working in virtualbox first, before polluting my real machines :) | 11:24.19 |
| chrisl | tor8: I very nearly created a 32 bit VM just for Skype, but then I realised I had a bunch of 32 bit libs installed anyway, so...... | 11:25.07 |
| paulgardiner | tor8 or Robin_Watts: the signature-creation stuff that Raed requires is on paul/master when you have a moment. | 11:26.45 |
| chrisl | tor8: FWIW I don't think there's ever been a 64 bit linux Skype client (from Skype, that is) | 11:27.02 |
| | Grrr, second call today from the "Windows Service Centre"...... | 11:29.42 |
| | tor8: possibly: http://www.tucows.com/preview/853867/Skype-For-Ubuntu-64-Bit ? | 11:32.39 |
| tor8 | chrisl: that one depends on ia32-libs | 11:41.49 |
| chrisl | tor8: all the others I could find do as well - so I guess Skype really never even tried :-( | 11:42.19 |
| tor8 | chrisl: I have it running on my chromebook, but egads skype really doesn't respect my DPI settings :( | 11:42.55 |
| | I have buttons the size of crumbs... | 11:43.03 |
| chrisl | Yeh, it doesn't make much effort to "fit in".... | 11:44.01 |
| tor8 | the font sizes in the contact list and message windows are alright, but the rest of the UI is unscaled | 11:44.39 |
| norbertj | tor8: ok, so my understanding was correct. I'll fix in our code, and wait for fixes to appear in main-line. | 11:52.29 |
| | tor8: and/or send patches with my fixes | 11:53.08 |
| Robin_Watts | paulgardiner: I have questions about that commit. | 12:06.49 |
| | setbits = ~Ff_Combo; looks wrong to me. | 12:07.11 |
| | Also if (setbits != 0 && clearbits != 0xffffffff) || rather than && maybe? | 12:07.40 |
| | pdf_create_widget surely needs more try/catchery? If the pdf_new_array fails, then we should unpick the pdf_create_annot? | 12:09.34 |
| | Or, possibly we should do it the other way around. | 12:10.29 |
| | fz_rect rect = fz_empty_rect, would be better. | 12:11.00 |
| | other than that, looks OK. | 12:11.37 |
| tor8 | Robin_Watts: paulgardiner: right, so the 500 or so odd errors are due to not having implemented the full regexp syntax :) | 12:28.40 |
| Robin_Watts | tor8: simple fix then :) | 12:33.22 |
| tor8 | Robin_Watts: yeah. either rewrite all paul's regexes to use a simpler syntax, or implement regexps :) | 12:38.32 |
| | paulgardiner: /[A-z]/ is that really what you mean, or should it be [A-Za-z] ? | 12:41.33 |
| paulgardiner | I'd guess the latter. Where is it used? | 12:54.38 |
| tor8 | util.printx among others | 12:55.24 |
| paulgardiner | I think if you simplify the regexps you'll complicate the overall structure. | 12:56.35 |
| tor8 | paulgardiner: no, I'm going to implement proper regexp handling in the long run. just wanted to see if we could make libjs + mupdf work with the current POSIX regexp syntax. | 12:58.23 |
| paulgardiner | Hmmm. Definitely should be [A-Za-z] | 12:59.42 |
| | Robin_Watts: thanks for looking at the commit. What have you noticed? | 13:00.55 |
| | Doh! I just need to read forward | 13:07.01 |
| | Robin_Watts: oh well done. First was a typo. Second: not sure what I was thinking! | 13:11.40 |
| | Robin_Watts: corrected version uploaded | 13:14.26 |
| kens | chrisl ping | 13:19.16 |
| chrisl | kens: pong | 13:20.05 |
| kens | Chris did you do somethign with zpdfawidthshow regarding word spacing ? | 13:20.26 |
| chrisl | kens: I added zpdfwidthshow | 13:20.52 |
| kens | And also the 'single_byte_space' in the text enumerator ? | 13:21.10 |
| chrisl | Yeh. | 13:21.26 |
| kens | OK tehn maybe you can illuminate me :-) | 13:21.33 |
| | If you look in gxchar.c, show_move() around line 924 | 13:21.49 |
| | There is a comment "we'll only apply the delta for single byte character codes == space.s_char" | 13:22.05 |
| | But... Nothing seems to check the size of teh space. | 13:22.18 |
| chrisl | Size of the space? | 13:22.47 |
| kens | We get here with penum->single_bytte_space is true, and never apply the word spacing, even if hte space is indeed a single byte | 13:22.48 |
| | It is a CIDFont with a single byte CMap, (at least as far as 0x20 is concerned) | 13:23.21 |
| | I see that the single_byte_space is set to false in the initialisation, then it just takes on whatever value it gets from pdfawidthshow or awidthshow | 13:24.38 |
| | We never (seem to) check the size of the space character | 13:24.59 |
| chrisl | The size of the character code should be derived from penum->fstack.depth | 13:25.33 |
| kens | By the way this is bug #695034, if you want to look at it I have a much reduced file | 13:25.40 |
| | penum-0>fstack.depth is 1 | 13:25.58 |
| | I'm not at all sure what it means by testing agains < 0 | 13:26.23 |
| chrisl | Hmm, I thought for a single byte character, depth should be 0..... | 13:26.36 |
| kens | Its definitely 1 for me, though I haven't checked why. I presume that simply means its a descendant | 13:27.02 |
| chrisl | I mean, for a single byte CID, depth should be 0 | 13:27.02 |
| | If the font is a single byte font, depth==-1 | 13:27.22 |
| kens | Hmm, not for me, the text is "I 1" and the Tj is <492031> Tj | 13:28.00 |
| | THe font has a single descendant | 13:28.27 |
| chrisl | Okay, can you send me the cut down file, and I'll have a look | 13:28.31 |
| kens | Sure | 13:28.39 |
| | OK its gone from here | 13:29.21 |
| chrisl | The single_byte_space space flag is to indicate whether we should check for the space being a single byte before applying. Because the behaviour is different between PS and PDF | 13:29.36 |
| kens | That much I figured, but I didn't work out the fstakc->depth test | 13:30.00 |
| chrisl | So the test maybe should be penum->fstack.depth <= 1 | 13:30.28 |
| kens | Well I can try that, I hadn't already because it baffled me :-) | 13:30.50 |
| | The CMap does seem ot be a single byte | 13:31.06 |
| chrisl | I couldn't find anything other that depth available at that point on which to judge | 13:31.42 |
| kens | wel <= 1 works OK for that test, I'[ll do a cluster run | 13:32.04 |
| chrisl | Maybe try the original test job first? | 13:32.28 |
| kens | pdfwrite has a 'decoded_bytes' value, not sure where it gets it form but that's what it uses for the spacing test | 13:32.46 |
| chrisl | Yes, but we don't pass anything like that around in general | 13:33.23 |
| kens | No definitely not, pdfwrite extracts it itself. | 13:33.37 |
| | THe original file seems fine with that change | 13:34.03 |
| chrisl | I wanted to try to avoid adding another entry to the standard enum | 13:34.24 |
| kens | Its a terrible way to do column spacing, mind you | 13:34.26 |
| | Hmm I'm behind tor in the queue, well mupdf doesn't take long | 13:35.11 |
| tor8 | kens: sorry. mujstest seems to take a fair bit longer than plain mupdf though. | 13:36.38 |
| kens | Not a problem tor8 | 13:36.49 |
| | its practically done, just bmpcmp to do | 13:37.03 |
| chrisl | Hmm, seems to cause a regression in one file :-( | 13:41.00 |
| kens | Really ? That was quick | 13:41.10 |
| | My test hasn't even started yet | 13:41.23 |
| chrisl | I should say "at least one file" - I'm looking at the two progressions I listed in the commit message | 13:41.39 |
| kens | ah.... | 13:41.45 |
| | It is using a descendant font, which is why fstack.depth is 1 | 13:42.15 |
| | I don't really see where teh fstack depth relates ot the number of bytes decoded | 13:42.46 |
| | ah, looks like pte->index may be relevant here. | 13:43.23 |
| | Its hte index (bytes) of the start of the next glyph I think | 13:43.43 |
| | Oh, but only if we didn't parse hte data from a CMap, because that updates the index itself | 13:44.14 |
| chrisl | I guess I'll need to add a field like the pdfwrite code has :-( | 13:44.46 |
| kens | I'm htinking it look slike it is required. | 13:44.59 |
| | We do need to know the number of bytes decoded for each glyph | 13:45.09 |
| | let me ppoke a little further | 13:45.16 |
| | Hmm, no I can't see an alternative | 13:48.56 |
| chrisl | No, neither can I - do you want me to take it on? | 13:49.37 |
| kens | I'll give it a bash, I'm sort of halfway through and I have lots of relevbant stuff noted down | 13:49.57 |
| | If I don't get it done today I may chuck it to you so it doesn't fester while I'm away | 13:50.15 |
| | It looks reasonanbly straight forward, and tehg enumerator is so large I don't believe its going to make much difference adding another int | 13:50.56 |
| chrisl | No, it just seemed a shame to add something for that one check, when there *appeared* to be an alternative | 13:51.52 |
| kens | Sadly I think the font stack depth is just that. WHile it may 'usually' be the case that descendants are only used for multi-byte fonts, I don't think that's a requirement. | 13:52.36 |
| tor8 | Robin_Watts: ping. | 14:01.31 |
| | I can't seem to match behaviour with the cluster using v8 | 14:02.04 |
| | http://ghostscript.com/~regression/tor/compare2.html towards the bottom | 14:02.19 |
| | 205: tests_private/pdf/forms/v1.6/zugangzeugnis.mjs | 14:02.37 |
| | the date that is shown as the reference, I don't get that | 14:03.16 |
| Robin_Watts | tor8: Ah, that might be a tor birthday thing. | 14:03.16 |
| tor8 | the mjs file has the text "TEXT Jun 15 1979" | 14:03.35 |
| Robin_Watts | right. | 14:04.01 |
| tor8 | but when I run that mjs file using mjstest with v8, I get an error message | 14:04.02 |
| | because it expects a date in the "dd.mm.yyyy" format | 14:04.12 |
| | which is not what I see on this bmpcmp | 14:04.23 |
| | Alert MuPDF: Invalid date/time. please ensure that the date/time exists. Field [ Unterschriftsdatum ] should match format dd.mm.yyyy | 14:04.57 |
| | and if I change the pdf-util.js to print the event.value, it has the text "Jun 15 1979" | 14:05.11 |
| | so that's pretty much expected, but what's going on with the cluster? | 14:05.23 |
| Robin_Watts | tor8: I really don't know. | 14:05.32 |
| tor8 | it looks like *all* the differences in this bmpcmp are due to date formatting somehow | 14:05.52 |
| chrisl | kens: I maybe confused, but it looks to me like pdfwrite is basically using the pte->index value | 14:06.39 |
| Robin_Watts | The make logs seem to show that angstroms is failing to build mujstest-v8x due to not having -lv8_base | 14:06.52 |
| kens | It is, that's how it sets bytes_decoded | 14:06.53 |
| | It sets it based ont eh old index and the new index (after extracting a glyph) | 14:07.12 |
| chrisl | So, if it's good enough for pdfwrite...... | 14:07.18 |
| kens | And that's exactly what I'm doing ;-) | 14:07.28 |
| | In show_proceed | 14:07.32 |
| | THe reason I need to store it is because we alter the index in show_proceed, but then use the size in show_move | 14:08.21 |
| | Or somethign like that | 14:08.25 |
| Robin_Watts | tor8: I wonder if every cluster node is failing to make mujstest-v8 | 14:08.50 |
| tor8 | Robin_Watts: mujstest-v8x is not the one that's run for the tests though (that's my hacking up the makefile to build both v8 and mujs versions, but name the mujs version the same as the old v8 so I can regression test it) | 14:08.54 |
| Robin_Watts | and what the hell is mujstest-v8x any wya? | 14:09.03 |
| | ah, ok. | 14:09.20 |
| kens | Of course this would go faster if I could type the same variable name consistently..... | 14:09.32 |
| Robin_Watts | but all the builds are failing to find v8_base, so neither mujstest-v8 or mujstest-v8x are being made. | 14:09.47 |
| tor8 | mujstest-v8 doesn't use v8 | 14:10.00 |
| | it's just named that way because I don't know how to run mujstest with another executable | 14:10.20 |
| Robin_Watts | ok. | 14:10.39 |
| kens | Hmm, that's irritating, the full file is better, but not correct | 14:10.52 |
| chrisl | Is it still worspacing that's the problem? | 14:11.24 |
| Robin_Watts | tor8: I don't know. | 14:11.52 |
| tor8 | it's rather odd how the code that runs the "reference" on the cluster seems to accept any date format for dates, but the v8 (and mujs) code I can run locally all expect it to obey the date format | 14:12.00 |
| kens | I'm not sure, but when I did the hack earlier with fstack.depth I think the file was 100% correct, so I believe so | 14:12.04 |
| Robin_Watts | You could try logging into peeved, and running the exes in /home/marcos/cluser | 14:12.18 |
| | You could try logging into peeved, and running the exes in /home/marcos/cluster | 14:12.20 |
| | /home/marcos/cluster/gs/bin/mujstest-v8 | 14:13.34 |
| | /home/marcos/cluster/head/bin/mujstest-v8 | 14:13.36 |
| | /home/marcos/cluster/head~1/bin/mujstest-v8 | 14:13.38 |
| kens | chrisl yes its still word spacing | 14:13.39 |
| | A quick hack to always apply word spacing works properly | 14:13.53 |
| chrisl | Oh, crap :-( | 14:14.05 |
| kens | I suspect I;'ve missed a path through the code, I'll check it now | 14:14.07 |
| | I think I may know where | 14:14.15 |
| Robin_Watts | I think this one is the latest: /home/marcos/cluster/mupdf/build/release/mujstest-v8 | 14:15.31 |
| | but it still dates from Feb 11th | 14:15.43 |
| tor8 | Robin_Watts: are those the 'reference' binaries? | 14:15.53 |
| Robin_Watts | head is the reference one, yes. | 14:16.09 |
| changelog | Hi everyone. Any MuPDF developers around? I've got a question regarding flattened pdfs | 14:16.22 |
| tor8 | Robin_Watts: where are the candidates? | 14:16.26 |
| | changelog: yes. | 14:16.35 |
| changelog | Hi tor! | 14:16.44 |
| Robin_Watts | tor8: looking now :) | 14:16.45 |
| changelog | I'm having some rendering issues with pre-flattened PDFs | 14:16.58 |
| | basically I see a ton of hairlines in the document. | 14:17.08 |
| | Is there anywhere I can post a picture of what I mean? | 14:17.25 |
| henrys | chrisl, kens: we planned a skype meeting about ghostdocs at 7:30 Pacific on skype, you are welcome if you are interested. | 14:17.28 |
| kens | THat's 15:30 UK ? | 14:17.44 |
| | voice or just data ? | 14:17.52 |
| henrys | data | 14:18.19 |
| kens | OK that's great, I'll lurk | 14:18.29 |
| Robin_Watts | tor8: /home/marcos/cluster/users/tor/mupdf/build/release/mujstest-v8 ? | 14:18.48 |
| chrisl | Hrm, Skype :-( OKay, I'll probably lurk, too...... | 14:18.58 |
| tor8 | Robin_Watts: that'd be it I reckon | 14:19.04 |
| Robin_Watts | will grab some lunch now to be back in time for the meeting. | 14:19.10 |
| henrys | I'm still trying to get a working skype since my mac died last night in a fiery inferno. | 14:19.13 |
| tor8 | changelog: what do you mean by preflattened? | 14:19.18 |
| kens | henrys flames ? | 14:19.23 |
| henrys | kens:well burning wires - I exaggerated a little | 14:19.47 |
| changelog | tor8: I mean, when there is no transparency, only chopped images. | 14:19.51 |
| tor8 | changelog: I still don't understand, maybe if you post an example pdf somewhere? | 14:20.29 |
| changelog | Doing just that. | 14:20.45 |
| henrys | chrisl: skype on linux would not work with my old facebook account - I had to make a new account and user name. | 14:21.36 |
| | chrisl: I guess it works okay for you. | 14:22.00 |
| chrisl | Facebook? I'm using a Skype account..... | 14:22.26 |
| henrys | chrisl: it used to let me authenticate with my facebook account like other services. | 14:22.53 |
| changelog | tor8: https://view.publitas.com/1307/12864/pdfs/f5baff3ef2d2dd9cdc81adca4cee6feb77512120.pdf | 14:22.53 |
| chrisl | henrys: Oh, I didn't see that option, so never tried it | 14:23.23 |
| changelog | tor8: First page is pretty bad (top left, where the sun is.) | 14:23.33 |
| tor8 | changelog: well, that's antialiasing for you :( | 14:24.27 |
| henrys | chrisl: I was looking at the Dell linux laptops, I didn't know they'd started that program again. I'm thinking of dumping mac - this is my 2nd bad hardware experience recently | 14:24.30 |
| changelog | tor8: anything I can do to reduce this? | 14:24.44 |
| | I've got some code I can post for you to look at. Could do with suggestions :-( | 14:24.57 |
| chrisl | henrys: Dell's policy about Linux seems to change with the direction of the wind..... I do rate their hardware, though | 14:25.06 |
| tor8 | changelog: flatten the entire image, rather than dozens of rotated overlapping parts | 14:25.41 |
| changelog | And is there a mupdf API I can use to do that? | 14:25.56 |
| tor8 | this is a problem with how the source pdf is constructed | 14:26.13 |
| changelog | true, but I can give you 10's of examples like this. | 14:26.33 |
| tor8 | in theory if you disable anti-aliasing (with the -b0 flag) we should not see this antialiasing + blending edge artefacts | 14:26.52 |
| | but the non-antialiased rendering isn't accurate enough so we get pixel cracks instead :( | 14:27.08 |
| changelog | Is that a build flag? | 14:27.09 |
| tor8 | changelog: command line flag | 14:27.16 |
| changelog | ah right | 14:27.20 |
| | Yikes! | 14:27.58 |
| kens | chrisl panic over, I'd missed the possibility of the glyph already being cached and wasn't properly resetting the count. THe original file is OK now | 14:28.01 |
| chrisl | kens: Oh, what about for cached glyphs? | 14:28.30 |
| kens | If the glyph was cached it wasn't exiting the loop, which meant I wasn't resetting the starting index | 14:28.50 |
| | D'oh ;-) | 14:28.59 |
| changelog | tor8: there's really nothing I can do? :-( | 14:29.17 |
| tor8 | changelog: yeah. the only way to render this sort of file "correctly" is to turn off AA | 14:29.21 |
| | and sadly, our non-AA path needs improvement | 14:29.36 |
| | changelog: you could use ghostscript. | 14:30.04 |
| changelog | tor8: currently, I do, but it takes forever and a day. | 14:30.32 |
| chrisl | tor8: with these butted images, you also need to render at the originally targeted resolution - otherwise there's always the chance of rounding errors | 14:30.49 |
| kens | It shouldn't be *that* slow..... | 14:30.57 |
| changelog | kens: you'd be surprised! | 14:31.06 |
| | besides, it almost has the same issues | 14:31.15 |
| tor8 | chrisl: yeah. but still, we get a lot more pixel cracks in mupdf's non-aa mode than I'm comfortable with | 14:31.19 |
| changelog | which means I have to render the image at a huge size and downscale it | 14:31.25 |
| | sort of covers the problem | 14:31.30 |
| kens | changelog, the simple answer is 'don't make a PDF file like that' | 14:31.30 |
| changelog | kens: let's assume we live in a world where that's not an option :-( | 14:31.44 |
| tor8 | changelog: yeah, if you want to render pdf files like that you really *have* to render without AA at a higher res and downsample | 14:31.55 |
| changelog | I get what you mean. MuPDF deals with transparencies beautifully | 14:31.59 |
| kens | Well, you have a solution, even if its slow | 14:32.00 |
| changelog | True. | 14:32.12 |
| chrisl | tor8: I'm inclined to blame the source file than the software | 14:32.13 |
| kens | As tor says, when you start with something bad, you have to go to extreme lengths to 'fix' it | 14:32.43 |
| changelog | Look guys, I do agree. | 14:32.51 |
| | But work with any PDF that is prepared for printing, and you get this. | 14:32.59 |
| tor8 | chrisl: mupdf should be able to cope with this in non-aa mode. feel free to open an enhancement bug and attach the file, saying something about pixel cracks and non-aa mode | 14:33.01 |
| kens | changelo not so | 14:33.08 |
| | We work with PDFs prepared for printing all the time and don't see this issue as particularly common | 14:33.28 |
| changelog | kens: you mean, flattened? | 14:33.40 |
| kens | Possibly the workflow you use/haev forced upon you does | 14:33.43 |
| | changelog don't flastten it, or if you must, don;t break it up into lots of images | 14:34.01 |
| tor8 | Robin_Watts: argh! I seem to have been confusing myself with which executable I'm running. | 14:34.43 |
| kens | Of course, if you are going to make a PDF file which consists of nothignmore than a stonking great image, then why botehr with a PDF file...... | 14:34.46 |
| changelog | Because this comes from retailers | 14:35.08 |
| | and the copy they send to the printers is the same they send to us | 14:35.15 |
| kens | SO why not just make a TIff :-) | 14:35.16 |
| | Is what I mean | 14:35.27 |
| | changelog I'm not sure what you expect from us. You have stated a problem, which we've answered and explained why there is nothing that can easily be done about it. | 14:36.34 |
| changelog | I'm past that. Just venting at the moment. Guess I was expecting a "there, there" | 14:36.53 |
| | Thank you for the help tho. | 14:37.00 |
| kens | If you aren't prepared to change the workflow (and yes I understand that may not be an option) then you have to live with the consequences | 14:37.01 |
| | We aren't good at sympathy, we're engineers ;-) | 14:37.28 |
| changelog | :-P | 14:37.34 |
| | Alright, here's another question for you. | 14:37.43 |
| | if I render this at a stupidly high DPI and downscale it | 14:37.54 |
| | will muPDF be able to do so without slanting the text too much? | 14:38.04 |
| kens | I'm not sure why it would slant the text, but I don;t see why not. | 14:38.24 |
| changelog | And, 1) can I render at high res without anti-aliasing and then scale it _WITH_ antialiasing? | 14:38.25 |
| kens | With GS if you sue one of the *scaled devices, yes | 14:38.55 |
| | You do it in one pass | 14:39.03 |
| | I'll have to leave MuPDF for those that know | 14:39.13 |
| changelog | tor8: care to weigh in? | 14:39.47 |
| tor8 | changelog: scaling down (with a bilinear/cubic/whatever filter) is the same as anti-aliasing, except "perfect" | 14:41.57 |
| | but like I said, mupdf can't render non-AA stuff like that file without getting cracks | 14:42.41 |
| | we could fix that given enough time and a bug report to remind us that it's important, | 14:43.02 |
| changelog | so I should generate a fz_pixmap with a high DPI, and fz_scale_pixmap | 14:43.12 |
| | I'll get the bug report written :-) | 14:43.25 |
| tor8 | changelog: yes. fz_scale_pixmap does proper filtering when downsampling. | 14:43.36 |
| changelog | how do I disable AA on a device? | 14:44.09 |
| tor8 | fz_set_aa_level | 14:44.33 |
| | fz_set_aa_level(0) to disable AA | 14:44.54 |
| kens | chrisl hmm 2 files showing differences with my latest cut | 14:45.03 |
| tor8 | fz_set_aa_level(8) to make it max quality | 14:45.04 |
| chrisl | kens: which ones? | 14:45.14 |
| tor8 | paulgardiner: ping. | 14:45.25 |
| | I think I've spotted another bug | 14:45.31 |
| paulgardiner | tor8: hi | 14:45.31 |
| tor8 | AFParseTime | 14:45.35 |
| kens | bug694436.pdf and 850_-_wrong_default_for_asian_fonts.pdf | 14:45.42 |
| tor8 | var nums = str.match(/\d+/) | 14:45.47 |
| | and then you switch on nums.length | 14:45.52 |
| | but nums.length will always be 1 | 14:46.05 |
| kens | chrisl just running a bmpcmp | 14:46.05 |
| tor8 | since the result of str.match() is an array with the results | 14:46.15 |
| chrisl | kens: it's possible these are progressions | 14:46.27 |
| kens | Yes, I have my fingers crossed :-) | 14:46.36 |
| tor8 | i.e. "foo123".match(/\d+/) is: ["123"] | 14:46.44 |
| paulgardiner | tor8: oh right. Nicely spotted. | 14:47.32 |
| tor8 | js> "123foo45".match(/\d+/g) | 14:48.01 |
| | ["123", "45"] | 14:48.05 |
| | or maybe that's what you actually wanted? | 14:48.25 |
| Robin_Watts | henrys: So do you need to readd us all as contacts on skype then? | 14:49.54 |
| tor8 | paulgardiner: actually, I think you may be doing the right thing after all... | 14:50.16 |
| chrisl | Robin_Watts: Contacts are in your Skype account aren't they? Not local? | 14:50.30 |
| paulgardiner | tor8: Oh, that seems unlikely! :-) | 14:50.37 |
| tor8 | "15:43am".match(/\d+/g) gives you ["15", "43"] | 14:50.39 |
| | but you have no case for "3am" :) | 14:50.47 |
| | paulgardiner: spotted it after doing some jslint cleanups to use all strict equality comparisons and the ampm equality comparison failed | 14:51.21 |
| | since the ampm was an array, that you compared with a string | 14:51.29 |
| Robin_Watts | chrisl: Yes, but didn't henrys say he'd made a new skype account? | 14:52.51 |
| changelog | tor8: Thanks! | 14:53.11 |
| paulgardiner | Ah yes. Strange I tested that a lot. I have an html file full of tests that work by pulling the js in | 14:53.24 |
| chrisl | Robin_Watts: Oh, I assumed that was originally, not yesterday..... | 14:53.29 |
| tor8 | Robin_Watts: the henrys skype account I have on my contact list is a "facebook" account | 14:55.00 |
| Robin_Watts | tor8: Me too. And he said he couldn't log into that. | 14:55.36 |
| tor8 | or at least it looks odd with that facebook: prefix | 14:55.40 |
| Robin_Watts | which means he'll need to readd us all. | 14:55.51 |
| henrys | tor8:and it works for you | 14:58.28 |
| | ? | 14:58.30 |
| Robin_Watts | You are listed as a contact for us, but you're not signed in. | 14:59.15 |
| henrys | ************* now. | 14:59.30 |
| kens | chrisl bug694436.pdf is almost identical, I can't tell if its better or worse, the other one looks like a *massive* progression | 15:01.52 |
| chrisl | kens: yes, I agree - I'm just onto the second page | 15:02.34 |
| kens | I'm comparing new vs 9.10 vs Acrobat | 15:02.55 |
| | THe justification on 9.10 is just wrong | 15:03.11 |
| chrisl | Yeh, I think that's a good fix | 15:05.00 |
| henrys | Robin_Watts: are we using the old group you had set up? | 15:05.22 |
| kens | Looks OK to me I'm just going to quickly review it and then I'll commiit it, its simple enough I don't think it needs much comments | 15:05.36 |
| chrisl | I looked at the change, and it looks sensible to me | 15:06.01 |
| kens | ah thanks chrisl | 15:06.09 |
| | I always like to check the diff in git gui, just to make sure :-) | 15:06.26 |
| chrisl | When it's a relatively simple diff, I can manage with the plain diff output | 15:07.18 |
| henrys | ray_laptop: we are having a skype discussion about ghostdocs if you want to join | 15:10.47 |
| marcosw_ | ray_laptop: not sure what's going on. Unfortunately I have to run, so did just restart ghostbot. I'll figure it out the next time it happens :-) | 17:41.20 |
| Robin_Watts | mvrhel_laptop: I'm uploading a new version of the GhostDocs.apk to my casper dir now. | 18:41.54 |
| | paulgardiner found that the previous one crashed with 3 out of 4 files. | 18:42.14 |
| | I've had to revert back to the horrible tar trick he was using before, but it does seem to work now. Absolutely no idea what was wrong. | 18:42.43 |
| | and that's the upload finished. | 18:42.49 |
| | marcosw: OK, example where the line spacing doesn't match please? | 19:07.46 |
| mvrhel_laptop | Robin_Watts: ok let me grab the nexus and add i | 19:10.45 |
| | it | 19:10.46 |
| | I will also get open office on it | 19:10.54 |
| chrisl | Oh, great, a Windows 8 Surface tablet bug :-( | 19:12.53 |
| mvrhel_laptop | chrisl for what product? | 19:21.50 |
| chrisl | Ghostscript | 19:21.57 |
| mvrhel_laptop | really. have we built gs for the ARM and winRT? | 19:23.07 |
| chrisl | It can be built for it, yes | 19:23.38 |
| | But just the DLL, IIRC, we don't currently have even a test harness for it | 19:24.21 |
| mvrhel_laptop | ok. I would think to do that we would need to be building with VS2012 or VS2013 | 19:25.18 |
| | I have run the remote debugger on the surface but that was for mupdf | 19:25.36 |
| chrisl | Yes, I used 2012 to do the ARM build | 19:25.49 |
| mvrhel_laptop | oh ok | 19:25.58 |
| Robin_Watts | oh, wow. The picsel font manager DOES look at gpos tables. | 19:26.10 |
| mvrhel_laptop | chrisl: can we run the remote debugger then? | 19:26.40 |
| | from the IDE? | 19:26.49 |
| chrisl | mvrhel_laptop: I've no idea - I've only ever built it, never run it, never seen it run..... | 19:27.10 |
| | mvrhel_laptop: does the surface have a command prompt? | 19:28.55 |
| mvrhel_laptop | chrisl: oh is it the solution in the winrt folder? | 19:29.01 |
| chrisl | Yes | 19:29.12 |
| mvrhel_laptop | hmm. does not build for me | 19:29.32 |
| chrisl | Although, I can't remember if that is setup for the ARM build, too | 19:29.40 |
| mvrhel_laptop | chrisl: yes. it has a command prompt window | 19:30.37 |
| chrisl | So, if it has a command prompt, I wonder if we can hack up the current GS Windows code to run on it? | 19:31.22 |
| | Yeh, it looks like I didn't add the ARM build to the solution/project - I should do that...... | 19:32.06 |
| Robin_Watts | WinRT doesn't offer the WIN32 entrypoints. | 19:32.25 |
| | at least, not all of them. | 19:32.32 |
| chrisl | Well, I did say "hack up"! | 19:32.47 |
| mvrhel_laptop | I think the better approach would be build a proper solution | 19:34.51 |
| | but the gs build is messy that I leave all of that fun to you chrisl | 19:35.26 |
| | mupdf was easy to get going | 19:35.38 |
| chrisl | mvrhel_laptop: I'll sort the build out, and add the ARM stuff to the solution, then we can talk about a way forward. I was hoping for a very short road to a very simple test harness..... | 19:36.37 |
| mvrhel_laptop | chrisl: if we can run the debugger in the IDE it is pretty easy to do a remote debug if we are doing the console app on the surface. | 19:37.47 |
| | it is like normal debugging | 19:38.13 |
| chrisl | mvrhel_laptop: we have *no* app on the surface (or WinRT) we *only* have a DLL | 19:38.15 |
| mvrhel_laptop | well we can build the console app if we can build the dll | 19:38.30 |
| | yes? | 19:38.42 |
| Robin_Watts | mvrhel_laptop: Presumably. The problematic APIs that I remember were in the windows gp functions, devices etc. i.e. all in the DLL. | 19:39.22 |
| mvrhel_laptop | I am not talking about a proper windows 8 app. just a build of win32c that will run in the desktop on the surface | 19:39.29 |
| chrisl | I don't know, it was paulgardiner that did the WinRT work, I just added the ARM build | 19:39.36 |
| mvrhel_laptop | I don't see that this is even related to WinRT just windows 8 on the surface | 19:42.41 |
| | looks like he is running in a desktop mode on the surface I am guessing | 19:43.23 |
| chrisl | I thought Windows 8 on the surface was WinRT..... | 19:43.33 |
| mvrhel_laptop | chrisl: good question. | 19:43.47 |
| | and you may be right | 19:44.03 |
| | but you can build desktop applications that are not winRT apps | 19:44.22 |
| | and have them run on the surface in the desktop | 19:44.38 |
| chrisl | But it is ARM, isn't it? | 19:45.21 |
| mvrhel_laptop | winRT is really geared toward the dev. apps | 19:45.25 |
| | yes ARM | 19:45.31 |
| chrisl | And the only ARM build we have is the WinRT code, so.... maybe that's his problem | 19:45.54 |
| mvrhel_laptop | oh yes. the winRT code would not be usable from a "desktop" application | 19:46.24 |
| | which is why we have to have a special mupdf app for desktop/tile app/win phone | 19:46.45 |
| Robin_Watts | So WinRT contains a desktop mode in which more of the standard WIN32 APIs are available than in the tile mode? | 19:47.21 |
| | window handling for a start, one would assume :) | 19:47.35 |
| chrisl | I did the ARM work for Raed and we did point out "no testing *at all*" and "any feedback appreciated" - and we heard nothing...... | 19:47.51 |
| mvrhel_laptop | Robin_Watts: it is a leaner version I don't know if all the standard API is availabe | 19:48.04 |
| | chrisl: I am wondering if you can add the ARM option to the standard gs VS project. It would have to be a VS2012/2013 project though I think | 19:48.46 |
| | and it would just build and run in the desktop mode on the surface. | 19:49.16 |
| chrisl | I'm just looking at that - but I'm failing to see how to map a network drive in Windows 8 :-( | 19:49.17 |
| mvrhel_laptop | I might be all wrong here though | 19:49.28 |
| chrisl | It's easy enough to try it, once I get a network share mapped to a drive letter....... | 19:50.54 |
| mvrhel_laptop | chrisl: it looks like this might not be possible | 19:53.28 |
| | let me try something simple | 19:53.55 |
| chrisl | mvrhel_laptop: that would not totally surprise me..... | 19:54.04 |
| | "Error: compiling desktop applications for ARM is not supported" :-( | 19:56.11 |
| mvrhel_laptop | right | 19:58.15 |
| | this is not going to work | 19:58.20 |
| | so we need to do the winRT approach for the surface | 19:58.29 |
| chrisl | Right now, I can't even remember how to do the ARM build...... | 19:59.28 |
| mvrhel_laptop | and as you say, have a test harness | 19:59.33 |
| | for the DLL | 19:59.37 |
| chrisl | Hmm, using the winrt/Ghostpdl.sln I can't work out what's going on, but if I open ghostscript_rt.vcxproj directly, it seems okay - color me confused...... | 20:14.39 |
| mvrhel_laptop | let me try that | 20:23.59 |
| chrisl | It looks to me as though the normal open of the output file should be fine with the WinRT code, though | 20:24.53 |
| mvrhel_laptop | still does not build for me :( | 20:25.58 |
| | I seem to always have these issues.... | 20:26.08 |
| chrisl | What're you getting? | 20:26.15 |
| mvrhel_laptop | Robin_Watts/henrys: so I have smart office 2 on here now. along with Robin's most recent apk of ghostdocs | 20:36.40 |
| | chrisl: Error1error C1189: #error : Unknown WINAPI_FAMILY value. Was it defined in terms of a WINAPI_PARTITION_* value?C:\Program Files (x86)\Windows Kits\8.1\Include\shared\winapifamily.h1161ghostscript | 20:37.12 |
| chrisl | I've no idea what that means :-( | 20:37.52 |
| mvrhel_laptop | the smartoffice 2 rendering of my power point is fast and looks really good | 20:37.59 |
| | chrisl: since you are not having the problem I think you are off the hook on that one. | 20:38.42 |
| Robin_Watts | and it looks different in GhostDocs ? | 20:38.43 |
| mvrhel_laptop | Robin_Watts: yes | 20:38.47 |
| | stuff is missing | 20:38.49 |
| Robin_Watts | Missing I can believe. | 20:38.55 |
| mvrhel_laptop | it takes a long time | 20:38.59 |
| Robin_Watts | Missing is a sign that the PDF export isn't working right. | 20:39.06 |
| | Missing is something that it may be feasible to fix. | 20:39.16 |
| mvrhel_laptop | also what is weird, is that if if the app has been running in the background and I bring it back up it seems to re-convert the whole thing | 20:39.56 |
| | is this correct? | 20:39.59 |
| chrisl | mvrhel_laptop: "Windows Kits" 8.0, you've got 8.1, that could account for the difference | 20:40.08 |
| Robin_Watts | I don't know. | 20:40.10 |
| | possibly. | 20:40.14 |
| mvrhel_laptop | it makes for a very slow demo | 20:40.18 |
| Robin_Watts | paulgardiner plumbed that bit in. | 20:40.25 |
| mvrhel_laptop | it would be nice to use the already converted file | 20:40.26 |
| Robin_Watts | It would. | 20:40.31 |
| mvrhel_laptop | Robin_Watts: also the font spacing is rather bad in ghostdocs | 20:40.47 |
| | it looks good in openoffice 2 | 20:40.53 |
| Robin_Watts | smart office 2? | 20:41.02 |
| mvrhel_laptop | yes | 20:41.06 |
| | sorry | 20:41.08 |
| | smart office 2 | 20:41.12 |
| | words are overlapping one another in ghostdocs | 20:41.26 |
| Robin_Watts | OK. The difference between the fonts in smartoffice2 and ghostdocs is that I've bent the metrics of the fonts to match the MS fonts. | 20:42.01 |
| mvrhel_laptop | kerning is all wrong | 20:42.02 |
| | or there is none | 20:42.10 |
| Robin_Watts | So I was expecting the spacings for the glyphs to be slightly off, but overall for it to layout better. | 20:42.52 |
| | I was under the impression that the changes I was making to the metrics were very small though. | 20:43.12 |
| | certainly I wouldn't have expected overlaps etc. | 20:43.22 |
| mvrhel_laptop | Robin_Watts: I think they (the overlaps) were there before. this is a power point don't know if that matters or if you changes were only for word | 20:44.11 |
| Robin_Watts | My changes were purely to the fonts. They should affect everything. | 20:44.26 |
| mvrhel_laptop | ok | 20:44.30 |
| Robin_Watts | But I don't see how SmartOffice can be getting it right, and we can be getting it wrong. | 20:44.44 |
| | Unless the PDF export is off, and I find that hard to believe. | 20:44.56 |
| mvrhel_laptop | well it is like night and day | 20:45.00 |
| Robin_Watts | Can I see an example file please? | 20:45.06 |
| mvrhel_laptop | I wonder if I can do a screen shot | 20:45.07 |
| Robin_Watts | Give me an example file, and I can run it through locally and get both bmps and pdf out and compare. | 20:45.34 |
| mvrhel_laptop | Robin_Watts: ok let me stick it on casper | 20:46.10 |
| | as it is large | 20:46.20 |
| | like all power poitns | 20:46.31 |
| | Robin_Watts: ok it is in my home directory. Linux_April_2013.pptx | 20:49.42 |
| | I have to head out for lunch | 20:50.09 |
| | indian buffet today | 20:50.12 |
| Robin_Watts | I'm off in a mo too. | 20:50.24 |
| | But this will give me something to weep at tomorrow. | 20:50.33 |
| mvrhel_laptop | Robin_Watts: ok thanks for all your work on this | 20:50.34 |
| | if I can help in anyway let me know | 20:50.41 |
| Robin_Watts | no worries. | 20:50.42 |
| mvrhel_laptop | if things go well with miles, the one thing will be a nice demo.... | 20:51.09 |
| Robin_Watts | I guess at worst you can demo Smart Office 2 and say "we are in the process of integrating this with MuPDF - here is a very early work in progress" etc. | 20:51.20 |
| mvrhel_laptop | exactly | 20:51.30 |
| chrisl | mvrhel_laptop: I'll update to Win8.1 tomorrow, and try a build with that | 20:52.56 |
| Robin_Watts | chrisl: AIUI you need VS2013 to build on 8.1 | 20:53.25 |
| mvrhel_laptop | yes | 20:53.37 |
| Robin_Watts | so unless you have VS2013 kicking around, I'd be wary of upgrading. | 20:53.41 |
| chrisl | Oh, really FFS, MS are *really* p*ssing me off..... | 20:54.02 |
| mvrhel_laptop | the 8/8.1 2012/2013 thing is really a mess | 20:54.08 |
| Robin_Watts | mvrhel_laptop: OK, I have bmps for the pptx here. | 20:54.24 |
| | And the first few pages look perfect. | 20:54.29 |
| mvrhel_laptop | Robin_Watts: let me go to a page... | 20:54.40 |
| | look at page 14 | 20:55.04 |
| | page 13 | 20:55.12 |
| | page 12 | 20:55.17 |
| | page 3 | 20:55.36 |
| Robin_Watts | All look fine to me. | 20:55.46 |
| mvrhel_laptop | all of those have overlapping words | 20:55.53 |
| | page 3. at the bottom. | 20:56.02 |
| | "at" overlaps with "www" | 20:56.18 |
| Robin_Watts | no, looks perfect to me. | 20:56.43 |
| mvrhel_laptop | Robin_Watts: perhaps the apk I grabbed was not the correct apk? | 20:56.47 |
| | that was the only "ghostdocs" apk I ever installed | 20:56.59 |
| | the earlier things was a mupdf variant | 20:57.13 |
| Robin_Watts | I'm looking at the bitmaps rendered by the Picsel code. | 20:57.29 |
| | i.e. what you would see in SO. | 20:57.33 |
| | I have yet to look at the PDF exported. | 20:57.46 |
| mvrhel_laptop | Robin_Watts: oh ok | 20:57.52 |
| Robin_Watts | I'm hoping that the PDF export is just broken. | 20:57.53 |
| | but the PDF export is crashing for me here :( | 20:58.00 |
| mvrhel_laptop | no the Picsel office app looks great | 20:58.06 |
| Robin_Watts | I am so so sick of this today. | 20:58.09 |
| mvrhel_laptop | Robin_Watts: :( sorry | 20:58.14 |
| Robin_Watts | It's not your fault! | 20:58.23 |
| mvrhel_laptop | Robin_Watts: I have to run out now | 20:58.38 |
| | the bus is leaving.... | 20:58.44 |
| Robin_Watts | I'll look at it tomorrow after I've taken out my frustration on some clays :) | 20:58.49 |
| mvrhel_laptop | have a good night! | 20:58.58 |
| Robin_Watts | OK. I can confirm that the pdf export is screwed. | 21:02.06 |
| | That's excellent news in a way. | 21:02.13 |
| mvrhel_laptop | Robin_Watts: ok good. I am glad to hear that you are seeing what I am seeing and that it is just the pdf export that is the issue | 22:31.55 |
| | Forward 1 day (to 2014/02/14)>>> | |
IRC Logs