| | <<<Back 1 day (to 2012/02/01) | 2012/02/02 |
| Robin_Watts | sebras: you here? | 00:05.04 |
| sebras | Robin_Watts: I am. | 00:05.25 |
| Robin_Watts | Just looking at the docs now. | 00:05.48 |
| sebras | Robin_Watts: alright. | 00:06.00 |
| Robin_Watts | Sometimes you don't document params. | 00:06.07 |
| | A lot of the time, you don't document context. | 00:06.20 |
| sebras | Robin_Watts: I never document context. | 00:06.35 |
| Robin_Watts | which I guess is kinda fair enough because all you'd say is "context: The context to use." | 00:06.41 |
| | right, so context is a special case. | 00:06.46 |
| sebras | exactly. | 00:06.47 |
| | so is pdf_document. | 00:06.55 |
| Robin_Watts | For fz_close(fz_stream *stm); you don't document stream. | 00:07.06 |
| | So are we adopting the convention that 'obvious' things are dropped? | 00:07.33 |
| sebras | no, I know. | 00:07.34 |
| | I think that was tor8's preference. | 00:07.45 |
| | I have extende the fz_close somewhat though, because the documentation should mention the reference counting. | 00:08.05 |
| tor8 | yeah. repeating the obvious is just plain obnoxious, for both the person reading and writing it. | 00:08.14 |
| Robin_Watts | My worry is when we start meeting things "that are obvious to me". | 00:08.45 |
| | but I'm prepared to shut up and see how it goes. | 00:08.58 |
| sebras | tor8: the only acceptable thing I can come to think of to write in such a scenario is to refer to another function and state where that list, page, object, whatever can be obtained. | 00:09.15 |
| Robin_Watts | Various things says "Will never return NULL". | 00:09.30 |
| sebras | Robin_Watts: yes, I've removed them. | 00:09.36 |
| Robin_Watts | So what do they say now? | 00:09.53 |
| tor8 | Robin_Watts: the 'context' parameter docs (and similar, used everywhere arguments) should go with the struct definition/typedef | 00:10.05 |
| sebras | Robin_Watts: the idioms or error handling, null-returns and reference counting should probably be documented elsewhere..? | 00:10.09 |
| Robin_Watts | Never returns NULL; throws exceptions in error cases. | 00:10.28 |
| tor8 | the default behaviour should be documented somewhere at the top, and exceptions, gotchas, and things that aren't the default >50% of the time | 00:10.54 |
| sebras | Robin_Watts: I guess it is better to explicitly state what function _may_ return NULL and leave the others undocumented, otherwise we'll have the line you just wrote for all functions... ;) | 00:11.06 |
| Robin_Watts | sebras: I'd rather have that line on every function, than have to go hunt at the top of the file to see what the default is for this particular section of headers. | 00:11.41 |
| | And I don't want to add a new function and have to check whether I've just made more than half the functions work one way and so need to change the docs everywhere. | 00:12.12 |
| sebras | Robin_Watts: I'm happy to do that too, but tor8 doesn't agree. | 00:12.17 |
| Robin_Watts | Whether a function can throw or not is HUGELY important. So much so that I wondered about having a #define THROWS thing. | 00:13.09 |
| tor8 | Robin_Watts: when 90% or so of functions behave one way, having to read and discard the same sentence over and over means you won't notice the "not" in the cases you do care about. | 00:13.10 |
| | though if it's something that varies a lot, then note it on every function | 00:13.36 |
| Robin_Watts | so we could say: THROWS fz_stream *fz_open_buffer(fz_context *ctx, fz_buffer *buf); | 00:13.44 |
| tor8 | Robin_Watts: a macro that may contain magic gcc __keywords or that we can scan for in a "check for common errors" script would be nice. but again I think almost all functions can throw exceptions given how much we use dynamic memory allocation. | 00:15.31 |
| Robin_Watts | I don't agree with tor8 on this, but it's his baby, so I'll shut up. Clearly what we're getting is MASSIVELY better than what we had before. | 00:15.45 |
| | tor8: First version of internal xps link support pushed. | 00:17.18 |
| sebras | Robin_Watts: I can only compare this to a situation at work today -- when reading about a function in gstreamer it's documentation noted that it may return a GST_FAILURE error code and that some state was undefined when it happened, but the documentation did not state _when_ this happened... | 00:17.35 |
| | Robin_Watts: so in some sence I agree with you, but I tend to agree with tor8 as well, because we should avoid cluttering the documentation unnecessarily. | 00:18.26 |
| Robin_Watts | sebras: That's why I'm attracted to the THROWS thing. | 00:18.50 |
| | I mean, we're basically trying to ape the kind of things that is in java. And that has something like that. | 00:19.34 |
| marcosw_ | alexcher: please take a look at http://bugs.ghostscript.com/show_bug.cgi?id=692832 as soon as you can. the customer says the issue is "is of high importance". | 00:19.46 |
| sebras | Robin_Watts: yeah, I understand why, but it is oh so ugly. :) | 00:19.54 |
| tor8 | I definitely prefer a THROWS macro (empty or not) and similar tags over comments saying the same | 00:20.06 |
| | like adding 'const' to all in-only pointer arguments | 00:20.30 |
| sebras | tor8: why do you prefer THROWS? because we can write scripts to locate them? | 00:20.58 |
| Robin_Watts | THROWS as a macro has the advantage that we can write a tool to check it at some later stage. | 00:20.59 |
| alexcher | marcosw_: I'm working on this problem now. | 00:21.10 |
| sebras | Robin_Watts tor8: so we settle for THROWS? | 00:21.14 |
| tor8 | exactly, and it's more in-your-face :) | 00:21.16 |
| marcosw_ | alexcher: thx | 00:21.18 |
| Robin_Watts | sebras: I like THROWS because it's a) small, b) it can be detected automatically in scripts etc, and c) it's at least pretending to be a formal definition. | 00:21.56 |
| | "Adding 'const' to all in-only pointer arguments" sounds bad to me. | 00:22.25 |
| | But equally, NOT having const anywhere in our source (the current situation) is not idea. | 00:22.49 |
| | ideal. | 00:22.50 |
| sebras | Robin_Watts: valid arguments. I'm just comparing it to people who #define STATIC static for release-builds and make it and empty macro for test-builds where they want their test code to be able to get at each compilation modules static variables... | 00:23.23 |
| Robin_Watts | The android thing gave a warning the other day because chartorune doesn't take const char when it should. | 00:23.34 |
| | and knowing that tor8 hates const, I cast around it in the android build, and feel dirty about it. And not in a good way. | 00:24.04 |
| tor8 | const is ... viral. either everywhere or nowhere. and so far I've been lazy, but if we're going to be all formal then I don't mind it. | 00:24.45 |
| sebras | tor8: I guess this release is about being _more_ formal at least, or so it seems to me. | 00:25.25 |
| tor8 | yeah. but const is a project for another day, possibly after 1.0 | 00:25.57 |
| | docs are more pressing | 00:26.01 |
| Robin_Watts | tor8: Adding const to places where stuff is genuinely const seems reasonable. (Yes, after 1.0) | 00:26.12 |
| sebras | tor8: const-ing also makes function declarations unwieldy. | 00:26.21 |
| Robin_Watts | It makes them longer, but clearer. | 00:26.49 |
| | It's only unwieldy if we insist on an indentation style where we don't wrap lines and format them nicely. oh, wait.... | 00:27.37 |
| | :) | 00:27.41 |
| sebras | Robin_Watts: :-D | 00:27.49 |
| tor8 | now now, we've all got widescreen monitors ;) | 00:27.59 |
| Robin_Watts | I have 2 1920x1200 monitors, but I'd rather not have to use both at once :) | 00:28.16 |
| tor8 | and failing that, you can always set your editor to use 2-space tabstops | 00:28.19 |
| sebras | true enough, my editor wraps at column 273. | 00:29.06 |
| Robin_Watts | No, because that way madness lies. | 00:29.12 |
| | sebras: what happens if you want to have 2 pieces of source up next to one another to compare? | 00:29.33 |
| sebras | Robin_Watts: then we wrap at 136 characters. | 00:30.23 |
| Robin_Watts | Anyway, this is all a side distraction, verging on a holy war. sebras: The docs look good to me. | 00:30.35 |
| sebras | Robin_Watts: coo.. | 00:30.50 |
| | cool. | 00:30.55 |
| | tor8: maybe it makes sense to wrap the function declarations in the headers nicely and not wrap the argument list in the function definition in the code? | 00:32.25 |
| tor8 | the main difference is we do the "returntype\nfunctionname(...)" formatting in the code but not the headers | 00:33.32 |
| sebras | I have also come across that argument names differ between code and headers. like ctm/top_ctm for fz_execute_display_list(). not sure if anyone cares about such details? | 00:34.06 |
| tor8 | make sure the header one has the best name and don't worry about it | 00:34.33 |
| sebras | tor8: I'm not changing it now, my commits will be pure comments or reordering of lines. | 00:35.20 |
| tor8 | like the case you mentioned, it's top_ctm in the code because it's clearer for the implementation | 00:35.23 |
| | but the caller doesn't care about that | 00:35.35 |
| sebras | tor8: yeah, it makes sense, but there are people that are religious about those things... | 00:35.55 |
| tor8 | I'm only religious about tabs... ;) | 00:36.13 |
| sebras | tor8: I force pushed my doc-branch. mostly more documented functions and minor changes elsewhere. | 00:37.31 |
| | tor8: my intention is to document all the functions mentioned in overview.txt in one commit and then go from there. | 00:37.52 |
| | tor8: have a look at it tomorrow. I must go to bed now, if not my project manager will make me wear a jesters hat tomorrow if I don't make the meetings starting time... | 00:38.44 |
| tor8 | sleep tight | 00:39.30 |
| Robin_Watts | night sebras. | 00:39.32 |
| | and everyone else | 00:39.36 |
| sebras | nn. | 00:39.59 |
| Robin_Watts | tor8: I'll have a crack at making remote links in xps work tomorrow. | 00:40.11 |
| tor8 | the "scheme://" type uris that xps_absolute_path didn't cope with I take it? | 00:40.34 |
| Robin_Watts | (at least in so far as having a URL that can be clicked on) | 00:40.40 |
| | yes. | 00:40.43 |
| | I'm wondering if we're expected to cope with having an xps document foo/bar/baz.xps that contains a link from a page to ../../../bibble.xps | 00:41.52 |
| | or worse, to ../../../bibble.xps#blurg | 00:42.21 |
| tor8 | no, I don't think relative urls outside the document are valid xps | 00:43.05 |
| Robin_Watts | That's a relief! | 00:43.19 |
| tor8 | hm, you're setting the clickable area as the link dest rectangle? | 00:44.42 |
| Robin_Watts | tor8: Yes. That's ass-backwards isn't it. | 00:52.47 |
| | Will fix that tomorrow. Thanks for spotting that. | 00:52.57 |
| kens2 | My turn for broadband problems :-( | 08:51.31 |
| chrisl | It's obviously a conspiracy :-( | 09:01.33 |
| kens2 | According to the ISP its their 'traffic management platofrm'. So I guess that means I'm being throttled. No updates until 10 am :-( | 09:02.06 |
| | Some sites are OK (IRC logs) some work, but slowly and some are basically crippled | 09:02.27 |
| | downloads are totally borked | 09:02.44 |
| chrisl | Bandwidth based? IRC is extremely low data rates | 09:02.54 |
| kens2 | Not IRC< the IRC logs, whicih are HTML (still small, but...) | 09:03.16 |
| | Some sites won't even open | 09:03.28 |
| chrisl | Could be protocol based, then - I've had sites with, for example, flash content fail to open, because the flash wasn't streaming - some sites, even disabling flash didn't help..... | 09:04.36 |
| kens2 | I already have slash (and other script) disabled by default :-) | 09:04.53 |
| | err. Flash | 09:04.58 |
| | Simple HTML works like lightning. Anything complex is slow, The Register front page is slow, and I can't get to many of the linked pages at all | 09:05.35 |
| | And now the IRC logs are stuck on last nigth too :-( | 09:06.43 |
| chrisl | Yeh, the problem is it *seems* like some sites won't complete loading until *something* happens with the flash stream - so even if flash is disabled, if the stream doesn't arrive, neither does the rest of the page. | 09:06.49 |
| kens2 | Whatever they are doign, they're making it worse.... | 09:06.55 |
| | Second attempt worked.... | 09:07.21 |
| chrisl | Hmm, my hand crafted widthshow with CIDFonts test file not only doesn't show the widthshow behaviour I expect with Distiller, but also shows different glyphs to Ghostscript..... me thinks I've made an error........ | 09:10.14 |
| kens2 | That does sound likely. | 09:10.30 |
| | chrisl do you know if I can use clang on Linux ? | 09:11.42 |
| | I obviously can't on Windows | 09:11.59 |
| chrisl | Yes, obviously you need to install it first....... | 09:12.08 |
| kens2 | Yeah ;-) | 09:12.15 |
| | Not today probably. I'm wondering how to look at Marcos's bug report. | 09:12.31 |
| chrisl | then do "CC=clang ./autogen.sh" | 09:12.42 |
| kens2 | Right. I may have to ask again | 09:12.56 |
| | I'll need a debug build as well (well 2 of them probably) | 09:13.08 |
| chrisl | "make debug" then | 09:13.33 |
| kens2 | <sigh> I guess I'll know when the broadband is fixed when I can get to the status page :-( | 09:13.47 |
| kens2 | decides to use the time profitably and goes to fetch coffee | 09:14.34 |
| chrisl | Personally, I'm ignoring that report for now - I looked into the one related to my CDevProc change, and that is almost certainly a compiler bug in clang | 09:14.43 |
| kens2 | I'm thinking my 2 probably are too | 09:19.28 |
| | But I will probably investigate it if I can get shot of my pettern problem. | 09:19.48 |
| chrisl | The problem, to prove my CDevProc one, I need to dig through assembler, and I'm not convinced it's a localised problem - given that Marcos said that compiling zfapi.c with lower optimisation made it work, but the change was in a different source file...... | 09:23.43 |
| kens2 | Yes, sounds like a compiler problem for sure. | 09:24.06 |
| chrisl | Compiler produced (especially optimised) assembler always gives me a headache :-( | 09:26.34 |
| | Hmm, Ghostscript, Jaws and HQN all agree on the output of my widthshow with CIDFont test file, only Distiller shows it differently - maybe I haven't made an error...... | 09:27.59 |
| kens2 | Could be a Distiller bug :-) | 09:28.11 |
| chrisl | Yes - that doesn't help me much, though...... the problem is, widthshow takes an integer to identify the character to add extra space to - so there's no way to differentiate between "32" and "0032" | 09:30.30 |
| kens2 | Well if its a Distiller bug you will just have to rely on the other interpreters. Or ask Ray to run a CPSI test | 09:31.17 |
| chrisl | Have you got distiller 10? | 09:32.06 |
| kens2 | Not yet, I keep meaning to buy Acrobat 10 | 09:32.17 |
| chrisl | Aha, the font is not being embedded by Distiller, that's probably the problem....... | 09:36.05 |
| kens2 | Yes, that would likely be a problem. | 09:36.27 |
| | Any idea why its not embedding it ? | 09:36.37 |
| chrisl | It says "due to licensing restrictions" | 09:36.57 |
| kens2 | What kind of font are you using ? | 09:37.10 |
| chrisl | CIDFontType 0 | 09:37.51 |
| kens2 | That's type 1 outlines ? | 09:38.01 |
| chrisl | Yes, it is | 09:38.18 |
| kens2 | Bizarre, there's no licencing info in type 1 | 09:38.31 |
| chrisl | Hmm, going by name, maybe? | 09:39.04 |
| kens2 | Possibly, what'ts the name ? You could change it easily anyway | 09:39.19 |
| chrisl | PingHei-Bold | 09:39.34 |
| kens2 | Not one I recognise. | 09:39.47 |
| chrisl | Annoyingly, using the "right-click->Convert to Adobe PDF" shortcut, it opens straight up Acrobat without a *hint* of a problem. Using Distiller explicitly, it emits the warning about the font embedding | 09:40.58 |
| kens2 | And teh right-click conversion is correct ? | 09:41.27 |
| | Maybe its your Distiller configuration | 09:41.40 |
| chrisl | No, the right-click conversion doesn't have the font embedded either - the lack of a hint of a problem is why I missed it first time around...... | 09:42.32 |
| kens2 | Ah. | 09:42.40 |
| chrisl | Actually, if looks like the font actually contains Type 2 outline - despite the CIDFontType - shouldn't matter, though, IIRC | 09:45.38 |
| kens2 | I think CFF fonts can contain licencing flags | 09:45.54 |
| | Hmm, maybe not. | 09:46.52 |
| chrisl | Yeh, I thought a "proper" CFF could, but not a PS font with Type 2 outlines.... but can't remember for sure | 09:47.37 |
| kens2 | It will still have to have CFF dicts won't it ? But I can't find any licencing stuff in the CFF format yet | 09:48.08 |
| chrisl | I'll have a quick play with it..... | 09:48.58 |
| | Well, that's got me really confused - not least because the font is already embedded in the Postscript file :-( | 09:55.29 |
| kens2 | Yeah, but we do that too, even if a TT font is embedded in teh incoming stream, we can refuse to embed it in an output PDF because of licencing flags | 09:56.33 |
| chrisl | But we don't, and GS is usually more strict that distiller | 09:57.35 |
| | I mean, pdfwrite happily embeds the font | 09:57.57 |
| kens2 | Sure, but I can't see why Distiller is complaining. I can't see any way to embed licencing in CFF fonts | 09:58.03 |
| | I might have missed it of course, and if so its possible we ignore it in GS too. | 09:58.29 |
| | We *used* to ignore TT restrictions... | 09:58.40 |
| chrisl | Well, I may have confused CFF with OTF - it's never totally clear to me where the OTF spec just means TTF | 10:00.03 |
| kens2 | OTF includes TT with CFF outlines | 10:00.17 |
| | I *think* that can have TT licence flags | 10:00.42 |
| chrisl | Hmm, generally, you throw away all the TTF boilerplate, and just execute the CFF stream in a CFF OTF font | 10:01.21 |
| kens2 | Distiller might not | 10:01.39 |
| chrisl | Nevertheless, this isn't an OTF, this is PS font | 10:02.02 |
| kens2 | Which is a conundrum | 10:02.13 |
| chrisl | I've also changed the name, and removed the copyright notices, to no avail. It's also been through fontforge several times...... | 10:03.00 |
| kens2 | Beats me, but who knows what Distiller does.... | 10:03.25 |
| chrisl | kens2: you can include "rights" information in "Type 1, Type 42 and CID" fonts - you use the FSType key | 10:09.42 |
| kens2 | Ah, thought there was a way, didn't realise it applies to type 1 too | 10:17.57 |
| | Do you have one present ? | 10:18.07 |
| chrisl | I'm going to check - I just followed a red herring in fontforge...... | 10:19.46 |
| kens2 | I can't even find FSType in the specifications... | 10:20.05 |
| chrisl | It's mentioned in the CFF spec p.56 | 10:22.26 |
| kens2 | The old or new one ? | 10:22.54 |
| | OK tech note 5147 | 10:23.08 |
| chrisl | Then details in: "Font Embedding Guidelines for Adobe Third-party Developers" | 10:23.31 |
| kens2 | Yes tech note 5147 :-) | 10:23.40 |
| chrisl | I didn't find it searching for the tech note, I could only find it using the title | 10:24.10 |
| kens2 | I have it under the tech note number | 10:24.22 |
| | Saved from some previous search I guess | 10:24.30 |
| chrisl | The CFF spec I've got is: Technical Note #5176, Version 1.0, 4 December 2003 | 10:24.43 |
| kens2 | That's the new one, I have one from 1996 as well | 10:24.59 |
| | Guess which one I searched ? :-( | 10:25.51 |
| chrisl | Ah, I think I've got that somewhere, but archived with other old docs from the Global Graphics days | 10:26.11 |
| kens2 | I bet pdfwrite doesn't even look for a /FSType key, even if GS puts it in the font dict. | 10:26.49 |
| | grep says no. | 10:27.22 |
| chrisl | It'll be there for T1 and T42 fonts, at least | 10:27.46 |
| kens2 | We don't use it though, apparently | 10:28.06 |
| chrisl | No, doesn't surprise me...... | 10:28.36 |
| kens2 | Me neither, its what I expected | 10:28.57 |
| chrisl | More coffee, I think...... | 10:28.59 |
| Robin_Watts | sebras: So, are you wearing a jesters hat? | 10:37.56 |
| sebras | Robin_Watts: no, I actually made it in time, but I did not log on to irc until now. | 10:38.27 |
| | Robin_Watts: though I intend to buy one late today and wear it on purpose tomorrow so I can be late. ;) | 10:38.59 |
| Robin_Watts | :) | 10:39.18 |
| kens2 | Great, the 10 am update says "as well as slower speeds custoemrs may now be experiencing data transfer issues..." So they've mad eit worse :-(* | 10:40.19 |
| | Hmmm. Well I've figured out my remaining ps2write problem, but fixing it will be a lot harder. The problem is its a pattern inside a pattern, and we aren't applying the matrix of the first pattern when calculating the step of the second pattern. | 10:58.21 |
| | I'm a bit puzzled, since it works fine in PDF. | 11:00.03 |
| chrisl | PDF anchors patterns differently, doesn't it? Maybe coping with that difference is going wrong? | 11:01.50 |
| kens2 | It does, yes, and the original is (of course0 a PDF file | 11:02.12 |
| | Its just that PDF seems to be applying the matrix (when I thought it wouldn't) and PostScript doesn't (when I thought it would) | 11:02.45 |
| | I must have my expectations upside down | 11:02.56 |
| chrisl | Presumably, the code has to do different things to handle the different behaviour, so the ps2write specific maybe wrong? | 11:03.29 |
| kens2 | There isn't any code to do things differently, that's the problem.... | 11:03.57 |
| chrisl | Hmm, well, I'd expect the output be wrong, but not really how you describe | 11:05.16 |
| kens2 | THe basic problem is this | 11:05.27 |
| | 2 patterns, one inside the other | 11:05.36 |
| | The first has a matrix of [.8 0 0 .8 0 -394] | 11:05.50 |
| | The second has a matrix of [1 0 0 1 0 1399] | 11:06.03 |
| | The 1399 needs to be 800 in PostScript (but not PDF) | 11:06.24 |
| | If you apply the first matrix to the second, you can see that the application moves Ty to ~800 | 11:06.49 |
| | So PostScript seems to be using the default CTM while PDF is using the 'current' CTM | 11:07.16 |
| | Which is hte opposite to what I thought happened. | 11:07.26 |
| | I'm going to go and read the PLRM now though | 11:07.34 |
| | Even though I understand it, applying it could be a problem. We don't keep a record of nesting depth | 11:08.01 |
| | So I don't know hot to 'undo' the parent pattern Matrix | 11:08.16 |
| | Ah, I think I see. | 11:10.04 |
| | The way ps2write works, it instnaitates the pattern before it is used, using makepattern. | 11:10.25 |
| | This locks the pattern to 'current' user space, which is of course the page. | 11:10.42 |
| | The makepattern needs to be deferred until the pattern is actually used. I wonder if that's possible. | 11:11.00 |
| chrisl | This is in the opdfread PS? | 11:11.07 |
| kens2 | Yes | 11:11.11 |
| chrisl | Yeuch! :-( | 11:11.24 |
| kens2 | We define all our pattern sup front (we have to for PDF) and the action of defining the pattern causes makepattern to get called. | 11:11.43 |
| | I guess I'm going to have to go and read that part of opdfread.ps now :-( | 11:12.32 |
| | At least I feel I'm making some progress with this one now | 11:12.57 |
| chrisl | BTW, I found the embedding problem: for some font types Distiller expects to be *granted* embedding rights by an FSType entry - the absence is not considered enough...... | 11:14.13 |
| kens2 | Oh good grief.... | 11:29.19 |
| | you would expect absence to be enough | 11:29.35 |
| | Oooh, nmy broadband seems to have recovered, I wonder how long that will last.... | 11:31.02 |
| chrisl | There doesn't seem to be an explanation of what makes a font require the permission granting - this is the first time I've stumbled over the this.... | 11:33.21 |
| kens2 | How did you find out it needed it ? | 11:33.36 |
| chrisl | I found a web page that said, basically, "if your font fails to embed and it should work, try adding the explicit FSType entry" | 11:34.38 |
| kens2 | An Adobe web page ? | 11:34.51 |
| chrisl | No, http://www.idautomation.com/kb/font-fstype-embedded.html | 11:35.23 |
| kens2 | Ah, so a font foundry. Would be nice if Adobe admitted it.... | 11:36.00 |
| chrisl | I'm sure there is a note somewhere from Adobe (in 3 point text, in the basement, in a disused toilet, behind a sign that says "Beware of the leopard".........) | 11:37.26 |
| Robin_Watts | paulgardiner: tell us your locking thing again, so tor8 can hear... | 13:07.13 |
| paulgardiner | I'm calling into libmupdf from severl threads, but in effect have a mutex locked around the calls. That's all fine, but it would be really handy if I could get the size of a page without locking. | 13:10.37 |
| | Calling pdf_load_page may be ok, but maybe not, if it messes with caches. | 13:11.07 |
| Robin_Watts | Just looking to see how we get the width/height of a page in pdfdraw | 13:12.45 |
| tor8 | the page dimensions are not available for xps without parsing the page at least partially | 13:13.38 |
| Robin_Watts | AFAICT we call pdf_bound_page, and pass it the page structure. | 13:13.48 |
| | And we get the page structure from pdf_load_page | 13:14.12 |
| tor8 | for pdf you can get around it since we have the page tree structure, but that won't work when we add in xps support | 13:14.18 |
| paulgardiner | That's a shame. Would have just simplified things a little. | 13:15.35 |
| tor8 | the load_page functions won't touch things in the resource store, but they do mess quite a bit with the pdf_xref type document contexts so will need locking | 13:16.35 |
| Robin_Watts | filmor was asking that we somehow make it possible to use xrefs from multiple threads at once. | 13:17.19 |
| | And that's hard. | 13:17.28 |
| tor8 | in the ios app I used the grand central dispatch to make sure I do heavy lifting in a background thread, and synchronize (like a mutex lock) the main thread whenever I need to touch the mupdf structs from the main thread | 13:17.53 |
| paulgardiner | At the moment, I have the app enumerating the page sizes on start up, but that's slowing start up (not surprisingly). I'll need to make sure the app can cope with learning the sizes as it goes. | 13:18.40 |
| tor8 | ah, yes, that's not going to work for xps at all I'm afraid | 13:19.09 |
| Robin_Watts | tor8: how minimal a parse do we have to do for xps to get the page size ? | 13:19.30 |
| tor8 | in the ios app I took the simple choice of always having "fit-to-screen" scaling so the actual page sizes don't matter for laying things out in the canvas | 13:19.35 |
| paulgardiner | I suspected so from the beginning. Just been putting off sorting it out until the end | 13:19.42 |
| tor8 | Robin_Watts: we need to decompress and parse the xml into the mini-dom-like structure | 13:19.59 |
| paulgardiner | I've copied the fit to screen for min zoom idea from the iOS app | 13:20.07 |
| | That does help as you say | 13:20.15 |
| Robin_Watts | Oh, and the xml libraries don't do that lazily? | 13:20.29 |
| tor8 | the iOS frameworks are madness for this sort of thing. I have nested scroll views to support both page flipping and zooming. | 13:20.42 |
| | Robin_Watts: nope. and there is no xml library, just my stupidly simple parser. | 13:21.25 |
| paulgardiner | I saw it. Clever trickery | 13:21.31 |
| tor8 | which could be made a magnitude faster by not malloc-ing every single string if I just set the pointers to point to the input data instead of doing a strdup | 13:22.06 |
| Robin_Watts | tor8: I'd imagine that most viewers capable of showing more than one page at a time would like to know width/heights for all pages fairly soon after startup. | 13:24.18 |
| tor8 | paulgardiner: I did toy with laying them out vertically as fit-width and have continuous scrolling as well | 13:24.48 |
| Robin_Watts | (Assuming they want to provide consistent scalings across all pages) | 13:24.53 |
| tor8 | that would probably be preferable for phone sized devices as opposed to tablets | 13:25.00 |
| | but then you get into having to deal with page sizes not being known until load time, as you say | 13:25.28 |
| Robin_Watts | tor8: IF we were going to do that, we should offer a menu of different layouts; 2 page up (starting on even pages, or odd pages) would be another popular choice. | 13:26.00 |
| tor8 | Robin_Watts: yeah. which is a real shame about XPS not consistently requiring the page dimensions in the fixed document sequence structures :( | 13:26.05 |
| paulgardiner | tor8: Glad you didn't: I' have had to match it in the Android app. :-) | 13:26.06 |
| tor8 | paulgardiner: I took the cue from apple's own iBooks reader and matched the general behaviour with that | 13:26.48 |
| paulgardiner | It seems very natural to use. | 13:27.15 |
| tor8 | slightly improved though, apple's reader has this annoying latency for single taps because they wait half a second for a "double tap" event before acting on it | 13:27.32 |
| | which drives me absolutely nuts | 13:28.02 |
| Agiofws | hey | 14:03.00 |
| | i need some help to set up a panasonic printer | 14:03.02 |
| Robin_Watts | Agiofs: weren't you here yesterday ? | 14:03.33 |
| Agiofws | i've tried connecting to it through ethernet and (ethernet to usb) but i have had no luck any pointers on the this matter ? | 14:03.34 |
| kens2 | He's in the irc logs :-) | 14:03.44 |
| Agiofws | the manufacture says though that to connect it to other unix linux systems you have to get a pcl controler module | 14:04.10 |
| Robin_Watts | I thought the consensus yesterday was that you needed a... yes, one of them. | 14:04.18 |
| Agiofws | why does that apply when a driver of this printer exists in cups server ? | 14:04.52 |
| | and why didn't the ethernet to usb (hack) work then ? | 14:05.16 |
| | DP 8016p | 14:05.30 |
| | bump ? | 14:06.18 |
| kens2 | We are not experts on the printer or CUPS..... | 14:06.43 |
| Agiofws | :) | 14:07.32 |
| chrisl | Agiofws: The standard Panasonic DP 8016p is a so-called "Windows GDI" printer - it relies on the Windows imaging system to create the page image. Not going to work with Linux | 14:11.50 |
| kens2 | That explains a lot | 14:12.37 |
| Agiofws | is there a linux imaging system ? | 14:12.57 |
| | how does linux printing work ? | 14:13.07 |
| sebras | chrisl Agiofws: unless one adds a controller module which makes the printer able to understand PCL which CUPS can generate. | 14:13.10 |
| kens2 | Not in the same ay, CUPS is as close as it gets I think | 14:13.21 |
| Agiofws | pcl controller costs 300E | 14:13.31 |
| | lol | 14:13.32 |
| chrisl | Agiofws: Linux printing works differently | 14:13.40 |
| Agiofws | just frustrates me that windows machines can use its ethernet port and linux cannot | 14:14.08 |
| kens2 | Its not the port that matters | 14:14.23 |
| Agiofws | its the protocol ? | 14:14.37 |
| kens2 | Its the printing technology | 14:14.37 |
| Agiofws | BUT the protocol is LPR | 14:14.47 |
| kens2 | GDI printer soncvert to bitmap on the host PC | 14:14.49 |
| Agiofws | and i state that in cups | 14:14.53 |
| chrisl | CUPS has support for PCL, PXL and Postscript (and various proprietary) printers, it does not support Window GDI printing. | 14:16.14 |
| Agiofws | ok | 14:17.35 |
| | i got a brick in my lounge | 14:17.45 |
| | :) | 14:17.46 |
| chrisl | FWIW, I think Panasonic's marketing is quite misleading on this subject, IMHO | 14:18.04 |
| sebras | chrisl: they do state that a controller module is required to support Unix/Linux... | 14:18.31 |
| chrisl | sebras: I didn't see that on the page I was looking at, and the manual download is a dead end | 14:21.06 |
| Agiofws | one more thing | 14:21.07 |
| | i tried to connect to its usb port through ethernet to usb connector should'nt that just work ? | 14:21.51 |
| kens2 | No, its not the protocol | 14:22.03 |
| Agiofws | its like a little print server | 14:22.03 |
| | kk | 14:22.32 |
| chrisl | Agiofws: if you *really* want a way to make this work, you *might* be able to setup a Windows machine as a CUPS print server - so your Linux box(es) would print to the CUPS printer on the Windows machine, and then it would use the normal Windows driver for the Panasonic to do the final stage. | 14:30.39 |
| | Agiofws: Please don't ask for my/our help if you go down that route - getting cups to work on Windows is a *very* black art right now, and I/we have *no* experience doing anything like that! | 14:31.56 |
| Agiofws | lol | 14:32.56 |
| | hmm windows machine up 24/7 just for a windows gdi printer ? | 14:33.17 |
| | windows cups server machine ? | 14:33.29 |
| chrisl | Personally, I'd do a bit of research and spend 50-100 bucks on an inkjet known to work with Linux - but that's just me! | 14:34.17 |
| Agiofws | why would cups run on windows and work with my printer when cups on linux does not ? | 14:34.19 |
| | ya i have one | 14:34.31 |
| | works fine | 14:34.34 |
| | photosmart something | 14:34.46 |
| chrisl | Agiofws: I don't know for sure that cups would work in this context. But I believe it can interface with the Windows printing API, so that would push it through the Panasonic driver as the "last stage", rather than the CUPS driver. | 14:36.05 |
| Agiofws | oh ok | 14:36.45 |
| | windows has an option to share a printer ... when you install it | 14:36.57 |
| | probably you could do that maybe | 14:37.07 |
| chrisl | Agiofws: (sorry, got a phone call) sharing a printer in Windows really just allows the output of the driver to be streamed across the network to a printer attached to another machine. It doesn't use the driver on "print serving machine" to create the page image. | 15:13.43 |
| kens2 | chrisl could the PDF interpreter redefine setcachedevice for type 3 fonts I wonder ? | 15:39.44 |
| | And replace the values with teh FotnBBox ? Which may also be wrong of course..... | 15:40.09 |
| chrisl | kens2: this is a Postscript file | 15:41.27 |
| kens2 | Oh, well its wrong then :-) | 15:41.45 |
| | have they tested on (not Distiller) otehr devices ? | 15:42.08 |
| | Not sure we should try to 'fix' this broken font | 15:42.32 |
| chrisl | Not that I know of - given who reported it, I doubt we'll get to say "no", though | 15:42.39 |
| | Also, parenthetically, redefining setcachedevice on the fly wouldn't work because we have to push systemdict and the font dict onto the dict stack before running the glyph procedure | 15:43.51 |
| kens2 | Was thinking PDF where it would be a translation of d0/d1 | 15:44.16 |
| chrisl | Oh, yes, not sure about that...... | 15:44.48 |
| kens2 | Well, obviously not going to work with PostScript :@) | 15:45.04 |
| chrisl | Actually I may have a better idea: if we check that the bbox is "sane", and if it's not, render uncached? | 15:45.17 |
| kens2 | Sure, but how do we know its 'sane' ? | 15:45.30 |
| chrisl | Well, in this case the "lower left" is higher than the "upper right" corner | 15:46.07 |
| kens2 | OK, but what if the font matrix is upside down ? | 15:46.20 |
| | That was my first thought last night | 15:46.34 |
| Robin_Watts | chrisl: A sanity check seems a reasonable approach. | 15:47.02 |
| chrisl | That shouldn't matter, I think - it's easy enough to test...... and easy enough to compensate for if necessary | 15:47.11 |
| Robin_Watts | The question is, will it survive in all cases ? | 15:47.17 |
| | It may be that this particular case is a matter of overflow. | 15:47.38 |
| kens2 | chrisl if you can check the font matrix and bbox, and show that the glyph is entirely clipped by the cache values, then I would be happy | 15:47.49 |
| chrisl | Well, we have worst of all cases right now: we get inconsistent results between cached and uncached - cached shows a tiny part each glyph, uncached shows the entire glyph | 15:48.16 |
| kens2 | Acrobat, of course, displays it all correctly. Probably because it has to translate the glyphs | 15:48.54 |
| Robin_Watts | Playing devils advocate here... Is it possible/permissible for a font to RELY on the clipping ? | 15:49.27 |
| kens2 | If the values are present they are expected to be correct. | 15:49.42 |
| | THere is no reason to draw ourtside the cache limits, and no benefit from doign so | 15:49.59 |
| chrisl | Distiller (and pdfwrite) ignore the parameters to setcachedevice and create their own from the bounding box for the marks in the glyph | 15:50.04 |
| Robin_Watts | ok. | 15:50.16 |
| kens2 | chrisl, yes thought so. Bet that's a Acrobat screenshot they've sent | 15:50.22 |
| | Would be interested to see a CPSI outptu, what do the 'other' PS rips do ? | 15:50.42 |
| chrisl | Jaws gives the same output we get now - clipped almost entirely cached, shows the whole glyph uncached. | 15:51.30 |
| kens2 | Well if CPSI does that too I think we have a strong case to take back to the customer. | 15:51.52 |
| | It doesn't work because its broken and other PS rips won't do it 'right' either | 15:52.09 |
| henrys_laptop | well ray has the CPSI rip ... | 15:53.08 |
| kens2 | Indeed. | 15:53.15 |
| Robin_Watts | kens2: I think they said it was a photoshop screenshot. | 15:53.57 |
| kens2 | From teh PLRM: | 15:54.29 |
| | "The declared bounding box must be correct—in otherwords, sufficiently large to enclose the entire glyph. If any marks fall outside thisbounding box, the result is unpredictable" | 15:54.30 |
| chrisl | HQN displays all the glyphs fully | 15:54.37 |
| kens2 | Typical | 15:54.42 |
| henrys_laptop | kens2:do we distill this okay? | 15:54.42 |
| kens2 | henrys_laptop : see chrisl comment above. | 15:54.58 |
| | yes, because we ignore the cahe, because its not a rendering device | 15:55.09 |
| henrys_laptop | so we do in a sense completely match adobe if the CPSI result is as expected. | 15:55.48 |
| kens2 | We match Distiller :-) | 15:55.58 |
| | SO yes, if the CPSI result matches our renderingt result, we are 100% compatible | 15:56.13 |
| henrys_laptop | I always assumed Acrobat was using distiller under the hood. | 15:56.28 |
| | when reading a PS | 15:56.34 |
| chrisl | Actually, that's odd: pdfwrite *doesn't* match Distiller for this one - but it did for the last "wrong parameters to setcachedevice" issue I looked at.... | 15:56.37 |
| kens2 | henrys_laptop : you mean Distiller is using CPSI ? | 15:56.46 |
| | Yes, but also, no. | 15:56.52 |
| | Its a CPSI with a *lot* of special hacks. It probably isn't very similar any more | 15:57.07 |
| henrys_laptop | no I am saying Acrobat does not have a PS rip but used distiller to convert to PDF first. | 15:57.24 |
| kens2 | Well yes, Acrobat can't open PostScript files. | 15:57.52 |
| henrys_laptop | oh my apple version does | 15:58.18 |
| kens2 | I mean it can't open them *direclty* but needs to convert them to PDF | 15:58.42 |
| henrys_laptop | right | 15:58.49 |
| Robin_Watts | (windows does the same as mac then) | 15:58.56 |
| chrisl | henrys_laptop: any idea what Apple Preview uses to view Postscript? | 15:59.04 |
| henrys_laptop | mac's have adobe distiller. | 15:59.22 |
| | an older version of it. | 15:59.29 |
| kens2 | Hmm, the pdfwrite output is half the size of the Distiller output.... | 15:59.41 |
| | And is missing the text, so its not the same as Distiller, as chrisl just said | 15:59.56 |
| chrisl | kens2: I don't understand that - as I said, the last time, exactly the same issue, pdfwrite ignored the setcachedevice..... | 16:00.40 |
| kens2 | Might be entirely different caue | 16:00.53 |
| | Hard to know wihtout debugging it. | 16:01.24 |
| chrisl | The only difference I can see is that the previous one, the glyphs were imagemasks, and this one, they are line art...... | 16:01.32 |
| kens2 | Not reallly inclined to spend time on it unless someone complains and we 'fix' it in rendering:-) | 16:02.12 |
| henrys_laptop | if cpsi does what we expect we still have a good case to go back regardless of their customer status. | 16:02.32 |
| kens2 | I think so too. | 16:02.39 |
| chrisl | Shall I send a mail to Ray, ask him nicely to try it? | 16:03.25 |
| kens2 | I think that would be best | 16:03.33 |
| henrys_laptop | nothing to be nice about | 16:04.21 |
| | "print this P1" is good enough | 16:05.13 |
| chrisl | ;-) Still, it costs nothing to be polite...... | 16:05.39 |
| henrys_laptop | brits and their manners | 16:06.10 |
| kens2 | THis is amusing: | 16:06.33 |
| | http://vimeo.com/jesserosten | 16:06.33 |
| | The 'Fotoshop' video. Courtesy of the Register | 16:06.33 |
| chrisl | henrys_laptop: I saw a thing the other day (I forget where) about the difference between Brits and Americans: "Americans tell you to 'have a nice day' and don't mean it - the British tell you to 'piss off', and do mean it" | 16:08.19 |
| Robin_Watts | chrisl: I think that's the English. The Scots will say something you can't understand that's actually far ruder, and mean it. | 16:11.38 |
| chrisl | :-) Fuapdjfsajk m[fgi - and I mean that! | 16:12.17 |
| henrys_laptop | I guess you guys are cranky - 60 million folks in what looks like enough space for my state of colorado. | 16:14.21 |
| kens2 | On average, teh US is less densely populated than the Highlands | 16:14.59 |
| chrisl | But definitely not down here in the south.... | 16:15.27 |
| | kens2: for that bug, I wasn't terribly worried about performance because well behaved glyphs will be cached, only naughty glyphs would take a significant hit | 16:16.13 |
| | <sigh> I think we need a custom operator for handing PDF word spacing :-( | 16:17.14 |
| kens2 | If you can reliably spot broken cachedevice calls, yes. | 16:17.22 |
| chrisl | kens2: well, using the bbox device it would be certain, but that looks like a lot of work. | 16:17.54 |
| kens2 | Yes, and that would be a performance drag, woudln't it ? | 16:18.41 |
| | OK only once per glyph for good glyphs, but.... | 16:18.56 |
| | in fact per glyph per font matrix | 16:19.47 |
| chrisl | Yes, but as you say, only once per good glyph, and also only for Type 3 fonts, which aren't that quick to start with...... | 16:19.54 |
| alexcher | Perhaps, we can just drop caching if any coordinate exceeds a hard-coded limit? Currently, gs uses the full fixed range as a limit. | 16:21.25 |
| Robin_Watts | I had a bug for mupdf last week, where colored type3 glyphs had to be treated as uncacheable. I wonder how gs coped with that... | 16:21.55 |
| kens2 | Correclty I expect | 16:22.16 |
| | setcharwidth expect glyphs to be unc ached | 16:22.28 |
| chrisl | alexcher: I did wonder about that, but I wasn't sure what would be a sensible value. | 16:23.26 |
| kens2 | 4096 ? Twice the canonical max for a TT font ? | 16:23.48 |
| chrisl | Type 3 fonts are a bit more unpredictable, I was erring towards something like 16k | 16:25.18 |
| kens2 | I still think we shuld see what CPSI does before changing anything | 16:25.58 |
| | BTW is the fotn created by Photoshop, or just included ? | 16:26.20 |
| | Hmm, Distiller doesn't even include these as type 3 fonts in the output PDF. | 16:27.39 |
| chrisl | It's pretty hard to tell. I don't think the Postscript is from an Adobe app - it was *way* too easy to cut down for that! | 16:29.20 |
| kens2 | I think it is.... | 16:32.09 |
| | %%BeginResource: procset Adobe_AGM_Utils 1.0 0 | 16:32.25 |
| | %%Version: 1.0 0 | 16:32.25 |
| | %%Copyright: Copyright(C)2000-2006 Adobe Systems, Inc. All Rights Reserved. | 16:32.25 |
| | Its an EPS that looks like it started life as a PDF file. | 16:32.47 |
| | But of course the buit with the fonts in might be another EPS from somewhere else. | 16:33.04 |
| | THe file is too big and complex to work with | 16:33.15 |
| chrisl | That's why I cut it down..... | 16:33.29 |
| | Anyway, I have to go. We'll see what CPSI does, and take it from there........ | 16:34.35 |
| kens2 | I think that's best | 16:34.46 |
| chrisl | alexcher: as this did turn out to be a font thing, and if you're busy with other stuff, feel free to hand it me, if you like. | 16:35.41 |
| | But, I really, really have to go - I'll check back when I get home later........ | 16:36.19 |
| henrys_laptop | Robin_Watts you are probably best to respond to the latest email from Miles | 16:49.56 |
| Robin_Watts | Hasn't arrived here yet. | 16:50.15 |
| | Has just arrived. | 16:50.50 |
| | I'll write a reply now. | 16:51.10 |
| henrys_laptop | really a 4 core ipad? | 16:52.42 |
| kens2 | Its a rumour isn't it ? | 16:53.01 |
| Robin_Watts | Well, the Asus Transformer Prime has a 4 core Tegra 3 ARM in it. | 16:53.25 |
| kens2 | http://www.reghardware.com/2012/02/02/leaked_photos_show_apple_ipad_3_cpu_model_code/ | 16:53.28 |
| Robin_Watts | (Actually, a 5 core thing - but either you use the 5th core or the first 4 in parallel for power) | 16:53.48 |
| | And hence people are guessing that the iPad will match it. | 16:54.03 |
| | I thought the latest rumor was that the iPad 3 (rumoured to be announced in feb, released in march) would be dual core, and the iPad 4 (or 3S or whatever) due in 6 months would be quad core. | 16:54.49 |
| kens2 | Anyway, unless they have a pipe into Apple (which seems unlikely) they are guessing about 4 cores as much as anyone else | 16:57.46 |
| | Goodnight everyone | 17:11.40 |
| Robin_Watts | ray_laptop: You should now have access to the jbig2dec.sourceforge.net stuff. | 17:23.44 |
| ray_laptop | Robin_Watts: OK -- did I want that ? | 17:27.54 |
| ray_laptop | goes to check IRC logs. | 17:28.10 |
| Robin_Watts | ray_laptop: Until yesterday only ralph giles had access :) | 17:28.17 |
| ray_laptop | Robin_Watts: Oh, I see. Thanks | 17:28.27 |
| | looks like I missed chrisl and kens | 17:28.54 |
| Robin_Watts | chrisl should be back later, I believe. | 17:30.10 |
| | tor8: XPS remote link stuff pushed. | 17:30.32 |
| | So on the job list, I think I'm out of things to do. | 17:30.48 |
| ray_laptop | Robin_Watts: well, once I get the profiles from cust 532, I'd welcome any help. We are finally getting the goals nailed down. | 17:34.18 |
| | Robin_Watts: I assume you have been seeing the emails from Eric | 17:34.45 |
| | Robin_Watts: from the 600 dpi 1-bit vs. 2-bit timings on WWTTN1CT, I'm considering doing a 32-bit multiple tile method instead of the standard halftone method in gdevm1 | 17:37.19 |
| | Robin_Watts: but I want to see the profiles to make sure there isn't something else going on. | 17:38.15 |
| Robin_Watts | ray_laptop: Sure. Anything I can do, please just say. | 17:40.56 |
| | I can always find things to do, but tor8 and I laid out the jobs we needed to do before the mupdf release, and he's indicated that he'd like to do the 2 remaining ones. | 17:41.49 |
| ray_laptop | Robin_Watts: As soon as we get the profiles, we can both look them over and two (or more) heads are better than 1. In the meantime, you can download the simulator and get it building | 17:42.49 |
| Robin_Watts | Are the ftp details in an email somewhere? | 17:43.42 |
| ray_laptop | Robin_Watts: I can give you the info on a private tab | 17:44.12 |
| Robin_Watts | ray_laptop: Or mail it to tech@artifex.com so we'll have a company-private record of it ? | 17:44.37 |
| ray_laptop | Robin_Watts: OK, I'll do that. | 17:44.56 |
| | darn, my FTP tool hides the password from me. I have to go back and search emails :-( | 17:45.42 |
| henrys_laptop | ray_laptop:chris (we) needed that bbox problem printer on cpsi? Don't know if you saw the logs. | 17:47.39 |
| ray_laptop | henrys: yes, I'll do that in a bit. I was going to ask chrisl if 600 dpi was OK since that's how it's configured currently | 17:49.00 |
| | henrys: chris had emailed me (and I haven't gone to the logs yet today) | 17:49.42 |
| henrys_laptop | I am sure 600 is fine, he sort of left in a rush and I wasn't sure if he forgot. | 17:50.34 |
| marcosw_ | henrys_laptop: oops, forgot the support meeting again (didn't have time in any case). Can we permanently move the support meeting to Wednesday at 9:30? | 17:53.31 |
| henrys_laptop | Robin_Watts:memento'ing the pdf server would be useful and I don't know if other folks have time to get to that. Until we don't have steady leaks I think we can't make a solid product announcement. | 17:53.53 |
| Robin_Watts | I thought that you'd permanently moved it (to friday?) last week? | 17:54.17 |
| | henrys_laptop: OK. | 17:54.29 |
| henrys_laptop | marcosw_:what Robin_Watts said | 17:54.32 |
| marcosw_ | did we? I know we discussed it but didn't recall that we had decided. Never mind then, see you tomorrow :-) | 17:55.05 |
| marcosw_ | thinks he better finish his PhD before the memory is completely gone | 17:55.18 |
| Robin_Watts | Valgrind out for MacOSX Lion. At last. | 17:56.39 |
| henrys_laptop | I use the valgrind svn and have had it for a long time but it doesn't detect everything at least compared with linux | 18:17.42 |
| Robin_Watts | henrys_laptop: Yeah, it was released in November - I obviously haven't checked since then. | 18:18.09 |
| | Still doesn't work properly for me. | 18:18.15 |
| henrys_laptop | I've always had to build it locally for it to work. | 18:18.41 |
| Robin_Watts | Yes, I just did. | 18:19.50 |
| | I built from the release snapshot. | 18:20.08 |
| | Interesting. release and debug versions of mupdfdraw give differing results on peeves. | 18:22.13 |
| | but valgrind gives both a clean bill of health. | 18:22.27 |
| | and windows debug/release give (2 more) differing results too. | 18:24.16 |
| henrys_laptop | the math functions are the usual suspects. | 18:26.51 |
| tkamppeter | When will GS 9.05 final get released, I have a small fix to add. | 18:27.04 |
| henrys_laptop | tkamppeter:it is in the works - can you send an email to chrisl? | 18:28.08 |
| tkamppeter | henrys_laptop, I will do so. | 18:29.10 |
| henrys_laptop | chrisl_away the link from ghostscript.com to the current documetation is not current. The directory http://ghostscript.com/doc/current should probably be a symbolic link pointing to the latest docs. What is there now is different than 9.04 maybe current is a copy of the 9.03 docs. | 18:41.30 |
| Robin_Watts | It's very close to 9.04 | 18:43.49 |
| henrys_laptop | yes just a few lines are different | 18:44.14 |
| Robin_Watts | Mostly changing US english <-> Proper english :) | 18:44.40 |
| ray_laptop | Robin_Watts: I sent the email for the cust 532 simulator and FTP site | 18:48.07 |
| Robin_Watts | ray_laptop: Thanks. | 18:48.36 |
| ray_laptop | Robin_Watts: in case you want to try getting it (90Mb) and building it | 18:48.37 |
| Robin_Watts | So, I've reduced the file to a single character. | 18:50.21 |
| | and the difference is in the antialiasing around the char. | 18:50.43 |
| ray_laptop | Robin_Watts: I forgot to mention in the email -- their code is 8.72-PRE-RELEASE *before* all of the ICC color changes, but with a LOT of patches for transparency and pattern-clist | 18:51.03 |
| Robin_Watts | yeah, I'm aware that it's a bit of a frankenstein. | 18:51.28 |
| henrys_laptop | ray_laptop:how much effort would it be to create a ghostscript device that reasonable emulates the simulator. where reasonable means most problems could be detected in ghostscript? I think we are on a bad course here. | 18:51.50 |
| ray_laptop | henrys: Huh ? | 18:52.18 |
| | henrys: the current project uses 'stock' 1-bit memory device (gdevm1) | 18:52.50 |
| | henrys: for 1-bit. For 2-bit, it wouldn't be hard to slap together a 2-bit device that has code similar to their 600 dpi 2-bit (halftone tiles from three threshold arrays) | 18:53.59 |
| | henrys: but what is your point ? | 18:54.14 |
| henrys_laptop | artifex engineering should be able to work on these problems in ghostscript not on their simulator. | 18:55.07 |
| ray_laptop | henrys: the previous color project that has an ASIC that does the rendering would mean creating a software graphics engine to interpret the data that we send to their engine -- also possible if we take their code | 18:56.18 |
| | henrys: but for performance issues we might as well run their simulator | 18:57.06 |
| henrys_laptop | the goal should be to have everything reproducible in ghostscript and have a device that acts as similar as possible so everyone can work on it, look at it, test it etc. | 18:59.38 |
| | where is this 2 bit halftoning code? | 19:00.06 |
| ray_laptop | henrys: it would also be possible to build a "stand-alone" gswin32c from their app that just does pnm output. That _might_ let us use a profiler like VerySleepy and not have multi-threads. | 19:00.36 |
| henrys_laptop | is the 2 bit halftoning code something we can look at? How do we run that in gs? | 19:01.09 |
| ray_laptop | henrys: the 2-bit halftoning code is in their device -- I can't put the file name here since it has their 3 letter name in it | 19:01.30 |
| | henrys: but currently the 2-bit code doesn't seem to be a particular bottleneck since we have the performance problem on the same files in all three mode | 19:02.50 |
| henrys_laptop | okay but we can create a similar device without their name in the filename right? | 19:02.51 |
| | I just feel generally the project is too removed from the rest of us. | 19:03.22 |
| ray_laptop | henrys: I'm still not following you | 19:03.23 |
| | henrys: everyone (at least everyone that gets support@artifex.com) gets the emails, and anyone can download the simulator. | 19:04.16 |
| | henrys: It is their insistence to remain pre-9.00 that keeps it away from the mainstream. | 19:04.53 |
| henrys_laptop | the simulator is an unfamiliar horrific monster -- if we had a device that behaved like the customers simulator it would be much simpler for everyone right? | 19:05.27 |
| ray_laptop | henrys: BTW, you were cc'ed on the email to chris with the FTP site info | 19:05.39 |
| henrys_laptop | no I have the simulator running no problem. it is one step above working directly on a printer it might be worse. | 19:06.48 |
| ray_laptop | henrys: It would probably be simpler for most to just build a standalone gswin32c using their code (with minimal changes) -- agreed. Let me have a quick look at doing that. | 19:06.49 |
| | henrys: It's just that I've gotten used to using their simulator, and maintaining / porting a separate build method when I get new versions from them hasn't seemed worthwhile | 19:08.06 |
| | henrys: and some of their issues may be due to their funky font substitution and their UFST hooks | 19:09.21 |
| | henrys: but by having our own copy of the UFST lib we are mostly isolated from the latter. | 19:09.54 |
| henrys_laptop | so there is no hardware to worry about for this product currently being worked on? | 19:10.15 |
| ray_laptop | henrys: correct -- their is no graphics engine -- we just deliver 1 or 2 bit raster buffers | 19:11.21 |
| Robin_Watts | Joy. So, as far as I can tell the mupdf indeterminisms are actually due to freetype giving back different renderings of the glyph for the same input values between release and debug modes. | 19:16.13 |
| ray_laptop | Robin_Watts: oops -- the top directory is different in _30_SIM than what I put in the email. It is actually 2lv_ctl (but that's minor) | 19:16.34 |
| | Robin_Watts: but don't we always do the regression testing with a release build ? | 19:17.06 |
| Robin_Watts | ray_laptop: I get different results between peeves and windows (and between debug/release on both) | 19:17.34 |
| | I'm therefore assuming it's the same problem. | 19:18.12 |
| ray_laptop | Robin_Watts: well differences between linux (peeves) and windows are not surprising, nor are differences between debug and release. But why does that explain regression indeterminisms ? | 19:18.47 |
| Robin_Watts | ray_laptop: I suspect that the differences seen in the cluster are down to the tests running on different machines each time. | 19:19.54 |
| | And that kind of instability ruins our tests. | 19:20.21 |
| ray_laptop | AFAIK, the regression always does a release build and we never compare windows results to linux results, right ? | 19:20.24 |
| | the windows regression test is just nightly and has separate md5sum database, right ? | 19:21.15 |
| Robin_Watts | ray_laptop: At the moment we don't have a windows regression box, no. But we could have. | 19:21.23 |
| | The problem is, (I think), that I'm seeing different linux machines give different results. | 19:21.48 |
| marcosw_ | Robin_Watts and ray_laptop: we'll have a nightly windows regression box real soon now. | 19:21.51 |
| ray_laptop | marcosw_: I guess I thought it was done. sorry. | 19:22.16 |
| marcosw_ | it should have been done months (years?) ago, I keep finding other things to do instead, just to avoid fighting with windows :-) | 19:22.57 |
| ray_laptop | Robin_Watts: well different linux machines is a horse of a different color (or many shifting colors) | 19:23.02 |
| Robin_Watts | Well, what do we expect if we build stuff that uses floating point :( | 19:23.40 |
| ray_laptop | if different linux machines give different results, all with a release build, then that should be testable -- a given machine should always give the same md5sum -- we just need to find which ones that give different sums (for the problem files) | 19:25.05 |
| | iirc, at one point we thought that AMD and Intel had differences, but we have both in the cluster currently | 19:25.51 |
| | Robin_Watts: and if freetype were to blame for mupdf indeterminism, we'd see that with GS too, right ? | 19:26.36 |
| Robin_Watts | marcosw_: Would it be possible to (overnight) run every job on every machine? | 19:27.01 |
| | ray_laptop: Maybe it is. | 19:27.29 |
| ray_laptop | Robin_Watts: can't you identify the subset of files that give indeterminism problems ? | 19:27.51 |
| Robin_Watts | I mean, maybe we are seeing this problem with gs - but it's buried in the number of interdermisms. | 19:27.57 |
| | ray_laptop: Well, I'd like to say it's the ones that gave differences on the last few commits :) | 19:28.16 |
| | but an exhaustive test would be good. | 19:28.32 |
| | (and wouldn't take that long) | 19:28.47 |
| marcosw_ | Robin_Watts: you mean on each cluster node? Most of them are already otherwise engaged (2 run performance regressions, 3 nightly regressions). | 19:29.08 |
| | btw, it takes ~5 hours to run all of the files. | 19:29.20 |
| Robin_Watts | Not all the mupdf test files? | 19:29.43 |
| marcosw_ | mupdf? no, what should be faster (about an hour). I thought you were asking about ghostscript. | 19:30.15 |
| Robin_Watts | No, it's mupdf that's occupying my mind here. | 19:30.28 |
| | MuPDF is much simpler than gs, so it's reasonable to hope that we don't have any *real* indetermisms. | 19:30.51 |
| marcosw_ | I should be able to hack something together without too much trouble. Just fool the cluster master to run a cluster job on only one machine. | 19:31.08 |
| | it would be sequential, but since have 10 machines that means 10 hours, so still overnight. | 19:31.38 |
| Robin_Watts | the exhaustive test would hopefully tell us what jobs are susceptible to this, and what 'classes' of machines we have. | 19:32.01 |
| ray_laptop | Robin_Watts: BTW, I'm building the latest and greatest sim (from Len) now, so I'll be able to make sure that I don't need to amend the instructions. | 19:37.26 |
| Robin_Watts | Download the simulator now. | 19:38.50 |
| ray_laptop | Robin_Watts: BTW, the latest cluster run from henry's commit only has 4 problems that look indeterministic -- all from pcl5efts | 19:42.22 |
| Robin_Watts | ray_laptop: That was still running! Clearly there are time dilation issues at play here :) | 19:43.36 |
| | ray_laptop: I was talking about mupdf. | 19:43.58 |
| | Look at the last few commits there. | 19:44.06 |
| | The last 4 commits at least should have had no changes at all. | 19:44.29 |
| | It's interesting that of the 8 differences in the last one, macpro was involved in 6 of them. | 19:45.15 |
| ray_laptop | Robin_Watts: I know -- I was pointing out that it _is_ possible to do predictable code that does PDF (and XPS) on 11 different machines -- and mupdf uses the same 3rd party libs as gs | 19:45.26 |
| Robin_Watts | ray_laptop: Right, yes. But as has been well established, mupdf and gs drive (say) freetype differently. | 19:46.21 |
| | In particular, we don't use the smooth renderer from freetype in gs. | 19:46.35 |
| ray_laptop | Robin_Watts: true -- gs doesn't get AA glyphs from freetype | 19:46.54 |
| ray_laptop | typed too slowly | 19:47.09 |
| Robin_Watts | Raising this issue with the freetype bods is unlikely to get a resolution; the only person who understood the freetype smooth renderer has been swallowed whole by google. | 19:47.54 |
| ray_laptop | Robin_Watts: so, if you use regular (non-smooth) rendering from FT, do regressions disappear ? | 19:48.36 |
| | s/regressions/indeterminisms/ | 19:49.01 |
| Robin_Watts | ray_laptop: No idea. It's not a trivial thing to try. | 19:49.04 |
| ray_laptop | Robin_Watts: just an idea -- I don't know how hard it would be | 19:50.02 |
| | Robin_Watts: the simulator builds "out of the box" :-) | 19:50.23 |
| | Robin_Watts: to switch print modes, there is also qp600_2bpp.ini | 19:52.10 |
| | Robin_Watts: and I cloned the qp600_1bpp.ini to make a qp1200_1bpp.ini just changing the lines for Default X DPI: and Default Y DPI: | 19:53.40 |
| | time for lunch... | 19:58.21 |
| | bbiaw | 19:58.24 |
| Robin_Watts | ray_laptop: What version of windows are you running? | 20:06.35 |
| | I'm on windows 7 here, and invoking devenv from the command line doesn't work for me. | 20:07.06 |
| ray_laptop | Robin_Watts: Win 7 Pro 64-bit | 20:07.06 |
| Robin_Watts | Have you disabled security or anything? | 20:07.21 |
| ray_laptop | Robin_Watts: running the setsim ? | 20:07.30 |
| Robin_Watts | yes. | 20:07.35 |
| ray_laptop | Robin_Watts: did you change it to use a particular version of VS as I did ? | 20:08.07 |
| Robin_Watts | OK, I have a devenv.com and it doesn't like that. | 20:08.43 |
| | devenv.exe is happier. | 20:08.48 |
| | it finds the .sln file, but then has problems finding the vcproj's. | 20:14.06 |
| | OK, so VS2005 is a non-starter. Need to use VS2008 | 20:14.50 |
| ray_laptop | Robin_Watts: does VS 2008 profile tool work for you > | 20:19.44 |
| Robin_Watts | Never tried it. | 20:19.57 |
| ray_laptop | iirc, mvrhel got it to work, but it never worked for me. He is on 32-bit Win7 I think (or was) | 20:22.47 |
| Robin_Watts | I get warnings about GenericResourceDirectory - is that expected? | 20:25.22 |
| chrisl | Robin_Watts: this (the warnings) is in cust 532's sim? | 20:41.05 |
| Robin_Watts | Yes. | 20:41.16 |
| | It seems to run OK, I just don't get the output. | 20:41.24 |
| chrisl | Yes, I get those, too. Do you know where the output ought to end up? | 20:41.47 |
| Robin_Watts | Well, I'm specifying d:\cvs\artifex\blah\out.kif | 20:42.38 |
| | and nothing is appearing in that directory | 20:42.49 |
| chrisl | Ah, that's not good. You don't see any errors? | 20:43.27 |
| Robin_Watts | Nope. | 20:43.41 |
| | Oh hold on... | 20:44.20 |
| chrisl | Hmm, I don't have the latest code yet..... | 20:44.26 |
| Robin_Watts | It's failing to open C:/temp | 20:45.04 |
| | and I'm not going to let it anyway. | 20:45.11 |
| chrisl | Oh, well, it does need a temp directory - I can't remember how to tell it where to use, though | 20:45.46 |
| Robin_Watts | It can write to D, but not C. | 20:47.10 |
| | C is my SSD and I don't want gigs of crap written to that to shorten its lifespan. | 20:47.28 |
| chrisl | Hmm, the temp file setting isn't where I thought it was :-( | 20:50.27 |
| Robin_Watts | It's in 2 places. Search for c:/temp and c://temp | 20:51.04 |
| chrisl | It doesn't bother me - I only have one drive on my Windows laptop | 20:51.39 |
| | tkamppeter: still here? | 21:03.27 |
| henrys_laptop | hi chrisl left a note about the documentation above. | 21:13.18 |
| chrisl | henrys_laptop: I was getting to it - I didn't quite understand what you meant. It doesn't have the changes from *after* 9.04? | 21:14.05 |
| henrys_laptop | well if you diff current and 9.04 they are different. I don't where current came from. | 21:14.38 |
| | when you realease I point the lawyer there as long as it is okay for 9.05 I'm good. | 21:15.25 |
| chrisl | Hmm, I thought what was in "current" matched what was in the 9.04 *release* archives. I made some corrections in the git versions to placate someone on bugzilla | 21:16.00 |
| | I *think* current used to actually mean "current", but we can't do that quite like we used to with subversion - we should really setup a cron task to update it every day or so | 21:17.30 |
| henrys_laptop | I assumed current would be a link that pointed to 9.04 in the same directory so assumed it was just a mistake. | 21:18.01 |
| | but you are probably right. | 21:18.29 |
| tkamppeter | chrisl, hi | 21:18.32 |
| chrisl | I think I tried that, but I couldn't get the sym link to work, for some reason.... | 21:18.35 |
| | tkamppeter: Hi, as henrys (I think) said earlier, if you e-mail the commits you want pulled into 9.05, I'll do that (you've missed the first release candidate, though) | 21:19.27 |
| | henrys_laptop: I will make sure that "current" is current when 9.05 is released *somehow* | 21:20.06 |
| henrys_laptop | great! | 21:20.22 |
| tkamppeter | chrisl, I am testing the RC now. I have found a bug already before touching the tarball, the fix I have committed and now I am testing the resulting snapshot. | 21:21.03 |
| henrys_laptop | Robin_Watts:have you tried the "deltas" recently. I had one going for quite some time never got output. | 21:21.49 |
| | ? | 21:21.53 |
| tkamppeter | chrisl, the bug was already there in 9.04 and now I have spotted and fixed it. | 21:21.55 |
| | chrisl, the change is only on cups/gdevcups.c, so it cannot break anything outside CUPS Raster. | 21:22.41 |
| chrisl | tkamppeter: yep, I'm happy to pull it in, it's just I'd like to do it tomorrow, so if you can drop me an e-mail it will make sure I don't forget | 21:23.46 |
| tkamppeter | chrisl, will do. | 21:24.47 |
| chrisl | tkamppeter: one thing: it looks like you pushed a merge commit | 21:24.51 |
| tkamppeter | chrisl, yes. I pushd to master at first and then did a 'git cherry-pick' of the two commits, so that one sees that the change is the same in the two branches. | 21:29.17 |
| chrisl | tkamppeter: In this case it's okay, but we usually prefer a rebase to a merge | 21:30.15 |
| tkamppeter | The fix is rather simple and only affects the CUPS Raster device. | 21:30.20 |
| | chrisl, how does a rebase of a patch from one branch to another work? For me cherry-pick looked like the "obvious" method to pass a change from one branch to another. | 21:31.33 |
| chrisl | tkamppeter: yes, to get a patch from one branch to another you cherry-pick, but when you "git pull" we use a rebase rather than merge to get up to date. | 21:33.07 |
| tkamppeter | What I did in the 905 branch is "git pull", "git cherry-pick ...", ..., "git push". | 21:35.35 |
| | chrisl, ^^ | 21:35.52 |
| chrisl | tkamppeter: This is on master, commit 2d4fac37ee36948c0b30e6b95292b68f718cafdc | 21:36.39 |
| | Robin_Watts: it's a miracle! That's the first version of the sim I've had that built out of the box. | 21:39.09 |
| tkamppeter | chrisl, what happened on master is that I did "git pull" and immediately after that I modified gs/cups/gdevcups.c, then did "gs commit" and with the editor open for entering the commit message I got interrupted for some time, came back, saved (not looking into my e-mail seeing that there was another commit) and did "git push" getting an error as the upstream repo has changed. In the message it told I should do "git pull" and I did so, ha | 21:43.07 |
| | ving a local repo with Henry's 72887eac commit and my change. Then I simply did "git push" to have everything upstream. | 21:43.08 |
| | s/gs commit/git commit/ | 21:43.53 |
| Robin_Watts | tkamppeter: The rule is to always check your history before you push. | 21:43.54 |
| chrisl | tkamppeter: yes, at the point where it said you 'should do "git pull"', for the ghostpdl archive, at least, we prefer that to be a "git pull --rebase" (I can't remember how you set it to default to rebase) | 21:45.16 |
| | s/archive/repos | 21:45.31 |
| tkamppeter | chrisl, I found this now in some writeup about GIT from Tim Waugh, he tells that the correct way is "git pull --rebase" in that case. | 21:46.55 |
| chrisl | tkamppeter: the preference does vary from project to project - we prefer rebase as it makes the cluster testing easier (amongst other reasons). As I said, it's not a big deal in this case. | 21:48.12 |
| tkamppeter | chrisl, does this message which I have seen come from the server? Perhaps one can hack this then to say "git pull --rebase". | 21:48.23 |
| | chrisl, does the merge step in the history trigger one addition, redundant regression run? | 21:49.19 |
| chrisl | tkamppeter: the message comes from your local client | 21:49.45 |
| | tkamppeter: yes, in this case we'll get a (benign, but pointess) extra cluster run. In more complex cases, with a merge, you can get non-working interim commits. | 21:50.48 |
| tkamppeter | chrisl, one can change the "git pull" default, see "man git-pull", section about --rebase, but I do not know whether one can configure this on the server to impose it to all clients. | 21:54.23 |
| Robin_Watts | tor8: Am I right in thinking that the ios app interprets in one thread and renders in another ? | 21:54.43 |
| chrisl | tkamppeter: no, I don't believe it can be imposed by the central repository, that would go totally against the git ethos. | 21:55.08 |
| Robin_Watts | We can configure the central server to refuse to accept merges. | 21:56.25 |
| | but that would be bad, because sometimes (when people are working on published branches) merges are what we want. | 21:56.47 |
| chrisl | It's not a measure I'd be in favour of...... | 21:58.25 |
| tor8 | Robin_Watts: no. I don't use a display list in ios. | 22:08.47 |
| tkamppeter | chrisl, state of the gs905 branch built correctly in the Ubuntu Precise package and seems to work correctly. | 22:09.41 |
| chrisl | tkamppeter: great, thanks for trying it. Fingers crossed, I'd really like only one release candidate this time...... | 22:11.23 |
| tkamppeter | chrisl, I have uploaded the package to Ubuntu Precise now, so that more people test it. Tomorrow you will then get the tons of bug reports ... | 22:13.36 |
| chrisl | tkamppeter: I'll just look the other way ;-) | 22:14.30 |
| tkamppeter | chrisl, I think there will not come many bug reports, as I had already uploaded the master snapshot of Jan 25 and this did not trigger any new bug report. And between that snapshot and the current one there are not a lot of differences. | 22:16.07 |
| | Forward 1 day (to 2012/02/03)>>> | |
IRC Logs