| | <<<Back 1 day (to 2014/07/15) | 2014/07/16 |
| kens | chrisl ping | 08:07.44 |
| chrisl | kens: pong | 08:09.43 |
| kens | chrisl did anyone respond on the mail from Scott "Re: Ghostscript drivers" | 08:10.18 |
| | Back on the 10th July | 08:10.33 |
| chrisl | Not that I've seen | 08:11.08 |
| kens | Oh, I suppose that means I'd better..... | 08:11.21 |
| | Not sure what to say exactly, I may talk to Michael first. | 08:11.37 |
| chrisl | Well, I'd say "not our problem" frankly! | 08:11.57 |
| kens | Its certainly true that its not our problem :-) | 08:12.14 |
| chrisl | I believe we'd have to pay M$ rather a lot of money (probably each release) to produce signed installers.... | 08:13.06 |
| kens | Huh, well I can't see us doing that. Not unless we need it for gsview, and especially not if you can install without needing the signing, and just get a warning. | 08:13.49 |
| chrisl | Oh, maybe the large amount of money is for the driver installer - there may be a cheaper option for an application. | 08:14.40 |
| kens | Hmm, I guess I might look at it. But frankly it really isn't our problem. | 08:15.07 |
| bugrapter | does any one knows LZOpenFile(), LZCopy() functions ? | 08:15.49 |
| kens | bugrapter these are apparently Windows API calls, nothing to do with Ghostscript | 08:16.48 |
| chrisl | kens: nsis would need updating, we'd need to buy a signature from someone like Verisign - it may be something we can consider at some point | 08:17.16 |
| bugrapter | chrisl i know but you guys are good at programming. so i'm just asking. | 08:20.10 |
| chrisl | Erm...... | 08:20.32 |
| kens | Maybe one day, but its probably not worth our while. THough maybe, as I say, for gsview. Which is why I might ask Michael about it. | 08:21.02 |
| | Its probably going to take me till this afternoon to get through this 'todo' pile anyway. | 08:21.32 |
| chrisl | kens: AIUI once we have a signature for Artifex, we can use it to sign all our products. And actually, nsis doesn't need updated, there is a way to do it with current releases | 08:22.25 |
| kens | Hmm, well I guess that would be nice, maybe. | 08:22.44 |
| chrisl | There will be a little "cleverness" required so we'd only try to sign the installer exe if the key is available. Also, do we need to sign all the exes, or just the installer, do you know? | 08:24.08 |
| kens | I think it depends whay exactly you are installing. 'Real' device drivers need to be signed, I don't think applications do, provided the installer is. TO be honest its not something I've looked at, and MS keep changing the rules with every version of Windows anyway. | 08:25.33 |
| chrisl | I know, that's one reason I've not paid much attention. But I think Win8 is going to force it on us :-( | 08:26.31 |
| kens | plans to ignore Windows 8 as long as possible.... | 08:26.48 |
| chrisl | concurs with that plan...... | 08:27.04 |
| | I'm going to take out life's frustrations on a little rubber ball - back in a 2-3 hours | 08:33.56 |
| kens | have fun | 08:34.02 |
| mattchz | good morning | 10:52.05 |
| | robin_watts: please would you mind reviewing the latest commit on matt/mupdf-private/master ? | 10:52.31 |
| | it reorders the build, so that upload is the final step. | 10:52.39 |
| | oh, hmm, robin_watts: you may have missed my earlier message. didnât realise you werenât in the room. | 11:15.56 |
| | please would you mind reviewing the latest commit on matt/mupdf-private/master ? it reorders the build, so that upload is the final step. | 11:16.31 |
| jogux | mattchz: oddly crashlytics didn't pick up the ios8 crash afaics. | 11:26.12 |
| mattchz | weird. | 11:26.19 |
| | Is there an NSLog in the output indicating that crashlytiocs was intialised? | 11:26.36 |
| jogux | dunno. need to try upgrading xcode to see if I can see the console :) | 11:26.48 |
| mlen | Hi! I'm using tiffsep device to split pdf file into grayscale separations. Is there a way to get the base color value for each separation during or after the process? | 12:18.06 |
| kens | Not sure what you mean by 'the base colour value' | 12:18.32 |
| mlen | For example when separating cyan I'd like to get rgba value of it | 12:19.47 |
| kens | There is no rgba value, its cyan..... | 12:20.05 |
| | Each grayscale is 0->255, which represents a percentage of the pure process ink (including spot colours) | 12:21.11 |
| mlen | Yes, I'm aware of that. | 12:21.30 |
| kens | There's no RGB involved anywhere, unless you specified the input as RGB, in which case, no there's no way to go back to RGB | 12:21.55 |
| mlen | The point is that I need to colorise the grayscales again | 12:21.56 |
| | so that when I overlay them, I'd get the original colors back | 12:22.47 |
| kens | Well I'd suggest you use something like Photoshop to do that. | 12:23.05 |
| mlen | Surely I'd do that, but it needs to be run as a batch job :( | 12:23.35 |
| kens | If you only need a preview, then tiffsep produces a composite as well I believe. | 12:24.05 |
| | Other than that, simply choose some values that you think represent Cyan etc relatively well in RGB space. | 12:24.31 |
| mlen | In the preview I also need to be able to toggle the layers, so that's the reason why I need to colorise them again | 12:25.05 |
| kens | Then just pick some reasonable values I'd say. If you have photoshop or something to hand, make a pure rectangle of each process colour and ask Photoshop what its RGB equivalent is | 12:25.57 |
| mlen | Ok, that's reasonable. How should I approach spot colors, then? | 12:26.32 |
| kens | Frankly, you can't. | 12:26.40 |
| mlen | To do the separations ghostscript must be able to get the values of these colors, right? | 12:27.26 |
| kens | The only thing you can do there is sample the tint transform which will give you a base space value, then convert the base space to whatever you need | 12:27.32 |
| | For tiffsep, no, Ghostscript doesn't convert the spot colours. | 12:28.01 |
| | a rectangle of 10% coca cola red is emitted as a 10% gray rectangle in the coca cola red separqation | 12:28.27 |
| mattchz | henrys / robin_watts: Iâm done now on mupdf, I think, apart from uploading a build to Apple. | 12:28.33 |
| | I can do this today, if people are happy that the RC build in Testflight is ok | 12:28.54 |
| mlen | kens: I see. Thanks for help! | 12:29.00 |
| mattchz | also, what do you want me to do next? | 12:29.02 |
| kens | mlen NP | 12:29.10 |
| | mlen for composite output in a given colour space, Ghostscript takes the percentage of the spot ink, runs that through the tint transform which will convert to 'n' values in a base space (gray, RGB or CMYK). If that is the same as the current device space we use those values, if not then we further convert the base space values into the current device space | 12:30.36 |
| | mlen if you override setcolorspace, its possible to write some PostScript which will sample the colour space and write edquivalent values on the back channel | 12:32.25 |
| mlen | The composite is basically a composition of every separation in the file, right? | 12:32.33 |
| kens | Not exactly | 12:32.40 |
| | We don't 'merge' the values. Wehn producing (for example) RGB composite output, every marking operation either writes RGB directly (the operation uses RGB space) or it writes in some other space. | 12:33.41 |
| | When it uses some other space (gray, CMYK) the interpreter does a colour space transformation internally to the required device space (in our case RGB) | 12:34.47 |
| | For complex spaces (Separation, DeviceN or even ICCBased) we run the 'tint transform'. THis is part of the colour space specification, and defines a way to map from the complex space to *a* base space. | 12:35.31 |
| | SO we run that. If the resulting base space isn't the same as the device space, then we run the same transformation as for simple spaces. | 12:35.57 |
| | Then we draw the object using those colour values. | 12:36.10 |
| | So, given that the tin transform is part of the colour space specification, you could write PostScript code which redefines that operator, and runs the tint transform with a 100% tiont. THat would then give you 'n' values, one per ink, in the base space (Gray, RGB or CMYK) | 12:37.26 |
| | You could then have Ghostscript send that information on the back channel (stdout) and capture it. | 12:38.00 |
| mlen | I didn't expect that something like this is possible :) | 12:39.02 |
| kens | PostScript is a flexible programming language, you can do all kinds of exciting thigs with it. Sadly, its not entirely easy..... | 12:39.32 |
| mlen | Can you please point me at some tutorial/book/or other resources? | 12:40.00 |
| kens | You might try Stack Overflow, I'd write somethign myself but I'm just back from vacation and trying to catch up on my email. Possibly chrisl r rayjj might welcome it as a simple challenge to divert them :-) | 12:41.04 |
| | If you can hang around a few hours I might be able to give it a try later. | 12:41.39 |
| mlen | Ok :) Thanks A LOT! | 12:42.32 |
| kens | NP | 12:42.38 |
| tor8 | Robin_Watts: chrisl: argh! have you seen todays font release from google/adobe? | 13:12.07 |
| kens | Google *and* Adobe ? | 13:12.22 |
| tor8 | kens: yeah. adobe's source font, and google's own rebranded version of it | 13:12.48 |
| | Adobe: Source Han Sans | 13:12.54 |
| | Google: Noto Han | 13:12.58 |
| kens | Yeah just looking at it now | 13:13.02 |
| tor8 | a full CJK font with variants for all the languages where the glyph designs differ | 13:13.15 |
| | shame about the size... 17M | 13:13.30 |
| kens | well 64k glyphs, hardly surprising ! | 13:13.41 |
| tor8 | droid sans fallback managed to squeeze into something really tiny (and that still has 50k+ glyphs) | 13:13.52 |
| kens | Doesn't do Vietnamese though | 13:13.53 |
| tor8 | kens: I thought vietnamese was mostly done using the latin alphabet and a stack of diacritics :) | 13:14.24 |
| kens | Umm, not sure, I thought it had some specific glyphs, but I was never involved with it | 13:15.01 |
| | tor8 it says the font offers seven weights | 13:15.34 |
| tor8 | kens: yeah, from hairline to black | 13:15.46 |
| kens | So is it a MM, or does it come as a family ? | 13:15.49 |
| tor8 | it's a family | 13:15.54 |
| kens | OK well that's somethimg | 13:16.01 |
| tor8 | but I expect the source is an MM | 13:16.05 |
| kens | We don't have to supply all 7 presumably | 13:16.12 |
| tor8 | but I suspect all the opentype magic voodoo (for selecting a variant, and vertical glyphs) doesn't mesh well with MM | 13:16.45 |
| | kens: I'd pick Normal or Regular and settle for that, as a substitute font | 13:17.10 |
| | but for GS maybe bick normal and a bold for the fontmap? | 13:17.22 |
| | s/bick/pick/ | 13:17.28 |
| | kens: you dropped off and missed a few messages :( | 13:18.22 |
| | I suspect all the opentype magic voodoo (for selecting a variant, and vertical glyphs) doesn't mesh well with MM | 13:18.30 |
| kens | Yeah, sorry, sudden network glitch | 13:18.32 |
| | gicve me a moment until logs catch up | 13:18.42 |
| tor8 | I'd pick normal or regular for mupdf, but for gs it might make sense to ship a bold weight as well | 13:18.54 |
| chrisl | I think I would just go with regular, too, and forget the different weights | 13:19.03 |
| kens | I'd be inclined to wtick with regular | 13:19.15 |
| tor8 | I have a test file here that starts working with Source Han Sans, that uses glyphs outside the BMP | 13:19.44 |
| kens | The font is going to be 'wrong' anyway, trying to match the weight (for Ghostscript) just seems silly | 13:19.45 |
| chrisl | We have code that "fakes" bold - although I'm not it applies to CIDFonts | 13:19.46 |
| kens | I'm not sure about that.... I suspect not | 13:20.04 |
| tor8 | and the TTC version makes it trivial to select the correct variant depending on the CID set in use | 13:20.29 |
| | only thing is ... I'd have to redo the stuff to pre-bake the vertical variants that I did for droid sans | 13:20.52 |
| kens | Ugh, I think at least we are spared that | 13:21.09 |
| tor8 | I expect I'll trim a megabyte or two of redundant TTF cmap and opentype lookup tables doing that though :) | 13:21.24 |
| | kens: I did prepare a TTC of DroidSans which has both -H and -V variants | 13:21.49 |
| kens | back out and leaves it to chrisl | 13:22.09 |
| tor8 | I use that in MuPDF, it might make sense to use it in GS as well for substitute fonts (unless you have other code to know which glyphs to rotate) | 13:22.15 |
| chrisl | There is some stuff which pulls in vertical substitute glyphs - I'm not entirely sure how it works..... | 13:23.00 |
| kens | tor8 I don't know how this works when rendering (if at all) I know that there are problems with pdfwrite when the PODF version < 1.4 as CIDFOnts are not supported and that seems to cause trouble | 13:23.16 |
| | I've nopt yet been bothered enough to try and fix the reported bugs, since the reports work if you don't stick to < 1.4 | 13:23.52 |
| jogux | mattchz: so, er, at least running on ios8 the TF build of mupdf seems to spam the full filename list to the console every 3 seconds. | 13:40.44 |
| | (console is working now, I had to reboot the device) | 13:41.00 |
| mattchz | yeah, it does that. | 13:41.17 |
| | tis nice | 13:41.18 |
| jogux | mattchz : it probably shouldn't at least in the appstore builds :-) | 13:41.30 |
| mattchz | probably shouldnât at all, tbh. | 13:41.39 |
| rayjj | mlen: I saw the dsicussion (still catching up on the logs) Are you still here ? | 13:41.40 |
| | mlen: tiffsep _does_ know what 100% of the separations are (collected from the tint transform). That's how it can develop the CMYK composite view from the separations. | 13:42.53 |
| | mlen: BTW, the Windows 'display' device also uses this to be able to show a composite view, but allow layers (separations) to be selected in or out of the view (when -dDisplayFormat=16#A0800 ) | 13:44.49 |
| chrisl | tor8: tbh, if I had my way, I'd be reducing our support for magically substituting fonts....... | 13:45.23 |
| rayjj | mlen: (and kens): Collection of the spot_equivalent_color is done by the DeviceN "helper" layer in gdevdevn.c | 13:45.38 |
| chrisl | rayjj: but that is all done internally, nowhere is that information accessible to the user | 13:46.21 |
| rayjj | chrisl: mlen: Well, the psdcmyk device also emits the "equivalent" cmyk (careful -- as additive) into the psd produced (see line 1164 of devices/gdevpsd.c). And it is a small matter of programming to modify the tiffsep device to emit the info along with the spot names | 13:50.43 |
| chrisl | rayjj: Yeh, I was wondering if it might be useful - maybe even use a custom/comment tag in the TIFF...... | 13:51.50 |
| mlen | rayjj: yes, I'm still here | 13:54.04 |
| rayjj | chrisl: mlen: the separation names are printed from gdevtsep.c line 2150 and the method to get the "equivalent" colors is in build_cmyk_map circa line 1741 | 13:54.35 |
| | mlen: I hope this helps. Decoding the header of a psdcmyk should be fairly easy and doesn't require rebuilding GS | 13:55.21 |
| tor8 | chrisl: if I had my way, I'd do like XPS -- require all fonts to be embedded | 13:55.59 |
| rayjj | mlen: but if you want to use tiffsep, then making the change in tiffsep should be just a SMOP | 13:56.02 |
| mlen | rayjj: thanks a lot :) I started learning postscript already, but your solution seems to be simpler :) | 13:56.07 |
| rayjj | mlen: glad I | 13:56.38 |
| chrisl | tor8: I don't mind the well defined list of available fonts, but after that, all fonts should be required to be embedded - anything else in insane! | 13:56.55 |
| rayjj | mlen: glad I noticed this discussion. bbiab -- coffee | 13:56.57 |
| chrisl | kens: we discussed a while back handling composite fonts with a type42 descendant...... | 13:59.34 |
| kens | chrisl there's a bug for that..... | 13:59.52 |
| chrisl | kens: yeh, I stumbled across pdf_convert_truetype_font() in gdevpdtf.c | 14:00.43 |
| kens | Hmm, converts TT to type 42 ? | 14:01.05 |
| chrisl | No "Convert True Type fonts into CID fonts for PDF/A." | 14:01.20 |
| kens | really ? Wow, I forgot about that | 14:01.34 |
| chrisl | I figured it might mean at least part of the problem had been solved....... | 14:02.00 |
| kens | It does sounds like it, though I can't remember the actual bug now | 14:02.16 |
| chrisl | kens: 695323 | 14:03.13 |
| kens | Hmm, right, so its an input file with a type 0 suing a type 42 descendant | 14:03.51 |
| | I'm not sure that pdf_convert_truetype_font helps here | 14:04.28 |
| chrisl | So, I'd assume by the time it gets to pdfwrite the type42 looks just like a TTF | 14:04.40 |
| kens | I'm not sure that's the case, the problem as I recall was getting the glyph info (character code or GID, I forget which) from the type 42 | 14:05.20 |
| | Because the composite font handling code wasn't prepared to deal with a type 42 font | 14:05.41 |
| | Obviously it can be done, it works when we aren't handling the type 42 as a type 0 descendant | 14:06.14 |
| rayjj | kens: but a type 42 is just a TTF with a PS wrapper, isn't it ? | 14:06.20 |
| kens | rayjj that's not really the point | 14:06.28 |
| | Its not a CIDFont | 14:06.34 |
| chrisl | What was part of the problem, yes.... I did say that pdf_convert_truetype_font() suggested *part* of the problem had been solved previously | 14:06.46 |
| | s/What/That | 14:06.54 |
| rayjj | kens: OK I'll stay out. I don't really like fonts | 14:07.00 |
| kens | And the composite font handling code is only prepared to deal with CIDFonts and type 1/CFF fonts as descendants | 14:07.02 |
| rayjj | uses Helvetica and TimesRoman and they usually work ;-) | 14:07.31 |
| kens | chrisl I think I was just going to import blocks of code from the non-composite case to handle the missing type 42 descendant case. | 14:07.42 |
| chrisl | kens: I thought you might get away with converting it to a CIDFont with a single byte encoding | 14:09.34 |
| kens | chrisl its possible, but I can't even remember what pdf_convert_truetype_font actually does, it probably only writes the font to a file. | 14:10.14 |
| chrisl | kens: I just thought I'd mention it before I forgot! | 14:11.51 |
| kens | Thanks, I may even get to look at it one day..... | 14:12.02 |
| Robin_Watts | mattchz: Reviews on mupdf-private look good to me. | 14:23.21 |
| mattchz | ta muchly. | 14:23.40 |
| jogux | mattchz: 6483930539 looks good to me. can't really go wrong deleting left over logging :-) | 14:36.41 |
| mattchz | indeed. | 14:37.19 |
| | thereâs lots of other bits too, we could remove, but thatâs the worst offender as it repeats. | 14:37.54 |
| jogux | nods | 14:38.01 |
| henrys | tor8 or mupdfâers do we have something to detect gray or color in the mupdf tools? - see the support message. You can respond or tell me and I will | 14:41.00 |
| Robin_Watts | henrys: We do not. | 14:41.17 |
| | But something could be written without too much pain. | 14:41.33 |
| henrys | Robin_Watts: always anticipating my next question ;-) | 14:41.55 |
| Robin_Watts | Basically we'd have a device (or a filter device possibly, now we have filters) that spotted non-grey things | 14:42.01 |
| henrys | Robin_Watts: I would like to get these guys going with mupdf but donât want to interrupt you is tor8 available for this? | 14:43.07 |
| tor8 | henrys: yeah, but Robin is more familiar with the way the filter device works | 14:43.54 |
| Robin_Watts | tor8: It needn't be a filter device. They just want something that can say greyscale or not. | 14:44.22 |
| tor8 | but I expect a more general version will need another filter mechanism on the device rather than interpreter filter | 14:44.33 |
| | Robin_Watts: yeah. so that would be a hundred line hack, just a device that looks at colors and nothing else | 14:45.09 |
| Robin_Watts | If we look forward to the days of managed color in mupdf, then certainly the filter device may not be the best way to do it. | 14:45.16 |
| | tor8: may be more than 100 lines if you have to allow for images possibly. | 14:45.35 |
| tor8 | yeah. a sink device that just returns YES or NO | 14:45.38 |
| | Robin_Watts: depends on how fancy you want to get | 14:45.45 |
| | a black-and-white image with RGB samples would be a falso positive with the 100 line hack | 14:46.01 |
| henrys | tor8:the relevant gs business is here: http://bugs.ghostscript.com/show_bug.cgi?id=695298 | 15:08.13 |
| | really? I open an html doc file in visual studio and it assumes itâs part of the project and tries to compile it. | 15:09.30 |
| kens | Mine doesn't do that.... | 15:10.07 |
| | I edit the HTML doc files in VS all the time | 15:10.16 |
| henrys | 2013? | 15:12.34 |
| kens | No 2008 | 15:12.40 |
| | I really don't like the GUI on 2013 | 15:13.02 |
| Robin_Watts | No edges, and LOTS OF CAPS. What's not to like? :) | 15:13.53 |
| kens | I'm not a fan of the colour scheme either :-) | 15:14.10 |
| mattchz | jogux / etc: new mupdf ios build. btw. | 15:14.16 |
| | henrys: iâm pretty much down on mupdf. | 15:19.42 |
| | s/down/done/ | 15:19.50 |
| | what would you like me to look at now? (just got the ios release build to do once weâve decided weâre happy with it). | 15:20.16 |
| jogux | mattchz : huh, weird, when I rotate my device mupdf changes page... | 15:22.37 |
| mattchz | oh? | 15:22.46 |
| jogux | that could be a core bug I guess | 15:24.33 |
| mattchz | nod. | 15:27.09 |
| | Iâll take a look | 15:27.12 |
| Robin_Watts | doesn't sound like a core bug. | 15:30.00 |
| mattchz | yeah, I can reproduce that. | 15:32.26 |
| tor8 | henrys: Robin_Watts: http://ghostscript.com/~tor/stuff/bw.c.txt | 15:32.45 |
| | those 100 lines | 15:32.54 |
| Robin_Watts | tor8: cool. commit it :) | 15:36.39 |
| | with docs etc :) | 15:36.51 |
| | and tradition would have you hook it up to mudraw :) | 15:37.06 |
| tor8 | it's too narrow in usefulness to commit | 15:37.07 |
| | now, if we could do this in javascript using mujs, or lua, we could just tell any user to run the "script" | 15:38.22 |
| Robin_Watts | It's exactly the building block that people need though. | 15:38.30 |
| tor8 | I can add it alongside docs/example.c | 15:38.54 |
| Robin_Watts | mudraw -e in.pdf could say "Page 1 is greyscale\nPage 2 is color\nPage 3 is greyscale\n" etc. | 15:39.01 |
| | I think it's worthy of being in the main lib as a device. | 15:39.21 |
| | If people don't use it it won't get linked in. | 15:39.28 |
| henrys | tor8: that should satisfy the customer unless they are expecting color management. | 15:49.11 |
| kens | Gee, nice of Alex to reduce the sample file for bug #695359. A 700Kb EPS file which renders to 102x12 inches and is *filled* with gradients...... | 15:50.42 |
| henrys | tor8: I think itâs fine but theyâll need a few words other than C to use it. You can respond or I will, let me know. | 15:51.32 |
| chrisl | kens: punt it back, and tell him to reduce - we *know* he can, after all | 15:53.48 |
| kens | Hmm, tempting..... | 15:53.59 |
| | I think I'll just put it to one side right now | 15:54.10 |
| rayjj | kens: sorry I forgot to cc support on the Gary Eden reply I did for Scott. I'll forward it now (now that you've also responded). | 16:05.55 |
| kens | :-) | 16:06.07 |
| | OK off to do something about dinner, goodnight all | 16:13.02 |
| mattchz | jogux: I think possibly the bug there is that we donât remember which page weâre on and readjusts after rotation afaics. | 16:14.03 |
| | I had to do something like that in other projects. | 16:14.13 |
| | (UIScrollView stuff) | 16:15.02 |
| mlen | rayjj: Thanks again, after a small patch I was able to print CMYK values to stdout :) | 16:30.45 |
| rayjj | mlen: Glad it worked out. If you want to submit a patch and sign an agreement to give us rights to it, we'd probably put it in the device as standard | 17:01.02 |
| | mlen: that way it will be in future releases. Otherwise, if we do it ourselves, we may not do it the same way, so your back end stdout processing would have to change. | 17:01.58 |
| | mlen: not promising to include it, of course, but we probably would | 17:02.16 |
| henrys | chrisl: we still have sprintf usage in the code - not gs_printf - dwmain.c | 17:02.18 |
| rayjj | Robin_Watts: for pageneutralcolor with gs -dGrayDetection it detects _source_ colors and uses a tolerance for close to neutral. Also it works for Lab and ICCBased input colorspaces | 17:03.38 |
| henrys | rayjj: does the customer need that? | 17:04.49 |
| rayjj | Robin_Watts: not sure if the mudraw device you are thinking of would perform similarly. Probably you should check with mvrhel_laptop for issues he tripped over. Maybe have him do it | 17:04.54 |
| | henrys: customer 801 needed that. This current customer, I don't know, since the capability was already in there. | 17:05.40 |
| henrys | rayjj: weâre talking about getting something together for hcl | 17:06.20 |
| rayjj | henrys: but this required a separate run of gs through the pages anyway, so maybe they can use gs for the analysis pass and mupdf for the pdf manipulation | 17:06.46 |
| | henrys: right. For customer 534/535 (I don't recall which) | 17:07.24 |
| | Good news -- my new office AC arrived today :-) | 17:08.19 |
| | Bad news -- it was (slightly) damaged :-( | 17:08.33 |
| chrisl | henrys: there are some places where we intentionally still use sprintf() - places where using the locale/code page may be required | 17:08.42 |
| henrys | chrisl: okay | 17:09.15 |
| | rayjj: maybe Iâll respond and find out why gs isnât working for them. Why did they request it in the first place? | 17:09.56 |
| mattchz | jogux: mind reviewing this please: http://git.ghostscript.com/?p=user/matt/mupdf.git;a=commit;h=dba796751448908c087441d414a50b78b4b62f09 | 17:17.43 |
| jogux | mattchz : LGTM | 17:18.46 |
| mattchz | ta | 17:18.50 |
| | we still reposition/zoom out when rotating, but I donât think thatâs too terrible. | 17:19.23 |
| | jogux: replacement fix: http://git.ghostscript.com/?p=user/matt/mupdf.git;a=commit;h=ebbd5b2638ce6b6f230e9f922d439b94b377d155 | 17:28.46 |
| | deleting those lines was a mistake. Looks like it was deliberate to change it when rotation finished, because during the animation we set a wider scrollview width to avoid clipping during the animation. | 17:29.39 |
| | (actually, it looks like we set the scrollview width twice during the relayout, so I could probably remove one instance of that, but Iâm too chicken) | 17:30.29 |
| jogux | ah right | 17:31.01 |
| | seems fine. might be worth a comment so we know what those lines are for? | 17:31.29 |
| mattchz | yeah, can do. | 17:31.36 |
| | jogux: howzat: http://git.ghostscript.com/?p=user/matt/mupdf.git;a=commitdiff;h=5c85915b5829d16129ee00f3eaba8ad0af2be552;hp=6483930539da2a48c37da7b508f05d71fc2c2d56 | 17:33.53 |
| jogux | mattchz: looks good. | 17:35.52 |
| rayjj | here goes, booting peeved | 18:25.07 |
| | peeved seems OK. I can ping casper. Now to wait until the cluster part starts... | 18:30.08 |
| | hurray! it's up | 18:31.24 |
| tor8 | henrys: please do, I don't like talking to customers :) I might spend some time tomorrow cleaning it up for inclusion in the main distribution and adding a flag to the mudraw so you may want to hold on a day or two | 18:36.05 |
| Robin_Watts | tor8: Including it would be really good, if only so we can point at it and say "see how easy devices are to write?" | 18:36.48 |
| tor8 | Robin_Watts: yeah. | 18:37.40 |
| rayjj | henrys: for the logs, see the email from HCL on 6/20. The problem they had with GS is when splitting pages it's too slow and they said it crashed on a 6000 page input file (but AFAIK they never gave us that file) | 18:46.04 |
| | henrys: that's why we steered them to mupdf for PDF splitting. AFAIK they can split first, then do the color/mono detect with GS. | 18:46.50 |
| henrys | rayjj: found that xpswrite bug, an sprintf horror - a uint64 with a %X ugh I thought 64 was okay with %X - it works on linux and mac | 18:51.20 |
| | rayjj: well I think my response is still okay, feel free to add something. | 18:52.35 |
| rayjj | henrys: your response to HCL seems fine, I guess. We do need to involve Miles or Scott if they (cust 534) are going to use mupdf to split pages or something since they only license gs AFAIK | 19:10.12 |
| | henrys: and they (HCL) claimed to have a file that "crashed" after a long time (6,000 pages) that we would still like to see. | 19:11.29 |
| | henrys: thanks for tracking down the xpswrite issue | 19:12.02 |
| henrys | rayjj: should have caught it faster - rusty | 19:12.56 |
| rayjj | henrys: xpswrite is fairly recent. I have to get out the WD-40 when I work on something I haven't touched for > 5 yrs ;-) | 19:19.23 |
| | but the details of sprintf would trip me up too, I suspect | 19:20.05 |
| henrys | a type check from the compiler would have been nice. I know gcc has some support for checking specifiiers agains âva_listâ | 19:21.38 |
| rayjj | BTW, peeves and peeved are on a faster connection now -- 12M into them and 1.5Mbits outbound. Still rather pokey for remote X11 I suspect | 19:22.36 |
| | henrys: yeah, for sprintf, but gs_sprintf ? How would it know ? | 19:23.24 |
| henrys | rayjj: I changed it sprintf to and visual studio still didnât help, didnât check gcc | 19:24.18 |
| rayjj | which VS version (not that I ever expect much help from VS or any Microsoft product) | 19:25.10 |
| | I'm installing VS 2013 (Express) to see if it's enough to let me build gsview (not much hope) | 19:25.53 |
| henrys | 2013 | 19:26.01 |
| rayjj | at least VS 2013 doesn't need Win 8 :-) | 19:26.08 |
| henrys | rayjj: any reason youâre holding back on 8 other than the usual? | 19:27.21 |
| rayjj | henrys: no -- I'm sure when I get my next laptop, I'll have to get Win 8, but since stuff works on 7, why upgrade ? | 19:28.38 |
| | and I don't need 8 for anything I'm working on ATm | 19:29.06 |
| | my twins have Win 8 on their laptops, and my wife's new laptop will as well, so I have plenty of experience finding out how to do stuff that is easier on XP, Vista or 7 | 19:36.08 |
| Robin_Watts | rayjj: Hopefully windows 9 will be out before I have to upgrade. | 19:45.57 |
| | microsoft do better with odd numbers. | 19:46.04 |
| rayjj | Robin_Watts: so which number counts -- VS 2008 is MSVC_VER==9 (and VS 2013 is VER 12) | 19:47.48 |
| Robin_Watts | I was talking of OS numbers (95,97, etc) | 19:48.50 |
| rayjj | Robin_Watts: but for the OS I agree --everytime MS tries to make a major change, it takes at least one version before it's decent | 19:48.54 |
| Robin_Watts | but VS2013 has an awful UI. | 19:49.21 |
| rayjj | I used Win 98 quite a bit and it seemed OK | 19:49.31 |
| Robin_Watts | No edges, crap colours and SHOUTY MENUS | 19:49.33 |
| rayjj | Robin_Watts: I can hardly wait :-/ | 19:49.52 |
| | mvrhel_laptop: so I installed VS2013 and cloned you mudf.git repo and checked out win_desktop and see platform/winrt/gsview/gsview.csproj | 22:48.10 |
| | mvrhel_laptop: I had problems with Install32.vdproj and Install64.vdproj -- am I supposed to be able to build gsview ? | 22:49.15 |
| | mvrhel_laptop: mostly I had a bunch of errors with 'sizeof' and a couple of include files | 22:50.12 |
| | mvrhel_laptop: this isn't at all urgent -- it's just a nice distraction from tracking down cust 532 memory issues | 22:51.01 |
| | which I will now dive back into :-( | 22:51.17 |
| mvrhel_laptop | rayjj: not sure why the issues with the installers. those are only if you are building the installers though. gsview should still build | 23:02.19 |
| | rayjj: you might not have the needed extensions installed for that | 23:06.58 |
| | I suspect that is the reason | 23:07.07 |
| henrys | marcosw: why are all the machines down? | 23:13.30 |
| | Forward 1 day (to 2014/07/17)>>> | |
IRC Logs