| | <<<Back 1 day (to 2015/03/29) | 20150330 |
| kens | chrisl here's an amusing one.... | 08:09.02 |
| | If I create a CIDToGIDMap where all the CIDS map to GID 0 Acrobat complains 'cannot extract the embedded font ....'. However, if I map them all to GID 1 instead, its perfectly happy. | 08:09.42 |
| chrisl | Hmm, that's a bit crap. But still a simpler solution than the current approach | 08:10.54 |
| kens | Yeah, it means I have to create a font with 2 glyphs, but hey.... | 08:11.10 |
| chrisl | They can still be empty glyphs. | 08:11.29 |
| kens | And teh Tesseract maintainer has indicated he'll be happy to accept that as a solution | 08:11.35 |
| chrisl | I should think so! Think of the work it will save him, long term! | 08:12.00 |
| kens | Well, because they don't ever render the glyphs, most tools are perfectly happy with the PDF file. Its only things like pdfwrite that get upset. | 08:13.00 |
| | But anyway, its a solution. Now I just need to create a satisfactory minimal TrueType font | 08:13.23 |
| chrisl | Nevertheless, his original approach would mean indefinitely increasing the number of glyphs in the font(s) as new languages are encountered - this is one solution for all languages, for ever. | 08:14.14 |
| Robin_Watts | chrisl: I wonder if the page 42 issue is that that's the point an A4 page hits 2Gig or something. | 08:30.42 |
| | (42 A4 pages hits 2Gig I mean) | 08:30.57 |
| chrisl | Robin_Watts: I've no idea, I just don't feel that it's "critical". And I didn't think we actually ship a Delphi binding for GS..... | 08:31.47 |
| Robin_Watts | chrisl: We don't, I'm sure. | 08:32.04 |
| | I don't feel it's critical either. | 08:32.14 |
| chrisl | In which case, it's really not our problem - I was just knackered last night to check properly | 08:32.32 |
| kens | I'd have made it 'normal' rather than trivial myself, and told him to reproduce it with a command line GS and then supply an example file. | 08:33.12 |
| chrisl | kens: It was the Delphi connection that made me label it as trivial | 08:33.42 |
| kens | chrisl he doesn't need to increase his glyph count, its as good for non-Latin languages as it is for Latin ones. THat is, its fine for as long as you don't render the glyphs, and no good for any language where we do have to access the font for real. | 08:34.05 |
| | chrisl well, if its a real bug we should fix it, but I'd have told him he'll have to reproduce it with GS so he can give us a command line, and if he can't do that, then I'd close it. | 08:34.50 |
| chrisl | I guess I just had an attack of the Hin-Taks..... | 08:35.55 |
| kens | I wouldn't say it was *that* bad :-) | 08:36.09 |
| chrisl | Are you kidding? I nearly banned him! | 08:36.26 |
| kens | :-D | 08:36.35 |
| chrisl | And it's clearly not a general Ghostscript problem as he said it happens on "any PDF's page 42". If Ghostscript couldn't get past page 42, we'd know about it PDQ! | 08:37.36 |
| kens | Well, maybe not if it was tiffsep, we don't test that on the cluster do we ? | 08:37.55 |
| | It might well need high resolution or something else which he hasn't told us. | 08:38.17 |
| chrisl | No, I don't think we test it but a decent number of people use tiffsep | 08:38.47 |
| kens | Like I said, could be configuration dependent. | 08:39.03 |
| chrisl | Oh, I didn't make it trivial, I made it minor.... | 08:39.16 |
| kens | I'd say its worth telling him to reproduce it with plain old GS so he can give us a command line, then when he can supply that and an example file, we'll look at it. | 08:39.45 |
| chrisl | I'll do so now..... | 08:40.07 |
| | I'll leave Robin_Watts's suggestion about the 2Gb limit until after the guy comes back and says it's only reproducible with his Delphi wrapper..... | 08:45.38 |
| kens | Makes sense | 08:45.47 |
| Robin_Watts | tor8: How goes MuPDF stuff? | 10:19.53 |
| | This transparency stuff is turning into a massive rabbithole. | 10:20.08 |
| | I think I understand it better now than I've ever done before, and I'd like to pursue it, but I don't think we should hold up the current release for it. | 10:20.44 |
| | There are a few bugfixes on robin/master. | 10:21.11 |
| tor8 | Robin_Watts: I'm thinking we should probably wait with the 64-bit changes until post release | 10:21.16 |
| Robin_Watts | tor8: ok... | 10:21.43 |
| tor8 | I also meant to ask you why you added typecasts to all the strlen calls | 10:22.01 |
| | (int)strlen everywhere | 10:22.06 |
| Robin_Watts | strlen returns size_t. | 10:22.23 |
| | and lots of places it was coded as int x = strlen(x) | 10:22.43 |
| tor8 | and you're passing it to size_t functions, yet casting to int first? | 10:22.44 |
| Robin_Watts | which is pretty much fine, until you do a 64bit build, when you get lots of warnings. | 10:23.15 |
| | ah, well, those casts are probably hangovers from early attempts and should go. | 10:23.37 |
| tor8 | there are two ways to solve this -- the cheating way by adding typecasts to silence warnings (and hide potential bugs), or the arduous way of actually using the correct types everywhere | 10:24.02 |
| | I don't like the first, because spurious typecasts just hide potential errors forever | 10:24.24 |
| | and the second is a *lot* of work | 10:24.34 |
| Robin_Watts | tor8: indeed. | 10:24.39 |
| tor8 | hence my proposing to wait until post release to do the big work | 10:25.01 |
| | MuJS is signed/unsigned and int size clean, I'd like to get mupdf to the same place | 10:25.13 |
| Robin_Watts | I think we need to finish running through the mupdf bugs to polish off the simple stuff and get a release out. | 10:25.15 |
| | tor8: That's an admirable aim. | 10:25.24 |
| tor8 | but it needs a lot of careful examining of our use of ints | 10:25.25 |
| | I think as a first step we could get the file functions to be 64-bit signed/unsigned 64/32-bit clean but not go down the full rabbit hole with the mallocs and everything else | 10:26.35 |
| | so yes, I think we should put that on hold for a bit and fix some of the low hanging bugs for the release | 10:27.34 |
| | the double fork to waitpid and remove zombie processes, I'm not 100% sold on that solution | 10:27.52 |
| | it looks too similar to the procedure to make a proper 'daemon', which also closes stdin/stdout to disconnect from the controlling TTY | 10:28.27 |
| | it smells like voodoo incantations | 10:28.35 |
| | the other ones look good, but I completely forgot to test the MINGW stuff last week... | 10:29.10 |
| Robin_Watts | tor8: Yes, it smells like unix voodoo, but it's self contained and there is a comment there to say why. | 10:29.30 |
| | I can't forsee it being a problem on anything, can you? | 10:30.15 |
| | mvrhel was going to look at 695861 | 10:30.46 |
| tor8 | Robin_Watts: no, it looks like a reasonable approach once I've studied it some more | 10:31.01 |
| Robin_Watts | tor8: cool. | 10:31.11 |
| tor8 | the lack of a second wait call in the first child worried me | 10:31.13 |
| Robin_Watts | We never waited in the original code. | 10:31.34 |
| tor8 | but since it exits immediately after forking, it shouldn't need to wait, the grandchild process will be reaped by init() | 10:31.41 |
| | the init process | 10:31.49 |
| | no, and that's why we left zombies around | 10:32.01 |
| | I *think* there's a call to do a non-blocking wait though | 10:32.16 |
| kens | Robin_Watts : I could see a difference with MuPDF 1.6 and the file in that bug report | 10:32.58 |
| Robin_Watts | I'm tempted to take the code as is, because we know it fixes the problem. | 10:33.04 |
| kens | Some content was not clipped out in MuPDF, where it is in Acrobat | 10:33.14 |
| Robin_Watts | kens: really? where should I be looking for the difference? | 10:33.15 |
| tor8 | wa can add a signal handler to catch SIGCHILD and call wait from there | 10:33.21 |
| | but this way works just as well | 10:33.26 |
| kens | One second and I'll reopen the file | 10:33.26 |
| | Robin_Watts : At the right edge of the page, There is 'A 12' in MuPDF and jsut 'A' in Acrobat | 10:34.18 |
| Robin_Watts | tor8: Do you want to handle the man page stuff? (695656 -> 695660) ? | 10:34.24 |
| | kens: Ah, I get 'A' in the latest mupdf. | 10:34.38 |
| | so I suspect we've fixed that already. Thanks. | 10:34.48 |
| kens | No problem | 10:34.53 |
| tor8 | Robin_Watts: yeah, I can update the manpages | 10:35.13 |
| | Robin_Watts: so the 7 fixes on robin/master (up to but not including the LARGE_FILE and FILE* ones) LGTM | 10:36.28 |
| Robin_Watts | tor8: So, can I push my fixes, up to and including "Avoid division by 0 in blend calls?" | 10:36.31 |
| | The last 2 transparency ones I want to hold back. | 10:36.43 |
| tor8 | though I'm taking your word for the transparency ones | 10:36.48 |
| | okay | 10:36.53 |
| Robin_Watts | tor8: balls. We didn't test the MinGW one. | 10:37.56 |
| tor8 | I wonder how we end up with the blend functions being called with negative numbers | 10:37.57 |
| | Robin_Watts: I'll test and and tweak it if it doesn't work | 10:38.09 |
| Robin_Watts | tor8: one of my reworks of the transparency stuff. | 10:38.18 |
| tor8 | ah. | 10:38.26 |
| Robin_Watts | but it's safer in that new form anyway. | 10:38.28 |
| tor8 | it is. | 10:38.33 |
| | the other option would be to change the input argument to be uint8_t | 10:38.46 |
| | and I think I prefer this, at least for now :) | 10:39.10 |
| Robin_Watts | Changing the input argument to be uint8_t would be bad. | 10:45.29 |
| | The current approach (and the approach that gs takes) is to render using normal blending, then 'undo' that blending in an 'uncomposite' step in order to redo the blending in the correct blend mode. | 10:46.06 |
| | That uncomposite step can result in rounding errors being expanded. | 10:46.32 |
| | I do wonder if it wouldn't be better to actually do blending correctly in the first place. | 10:46.50 |
| | It would mean updating the code for blitting the scan converted buffers, and the image plotting code. | 10:47.12 |
| | but would result in faster code overall, I think. | 10:47.31 |
| tor8 | could use another set of the 'generic' (n-component) paint functions but with added blendmode argument? | 11:16.21 |
| Robin_Watts | tor8: yeah. | 11:17.17 |
| | though we'd need to add more arguments too. | 11:17.30 |
| | like a backdrop pointer (the general form blends a backdrop + shape onto a destination, currently we assume backdrop == destination) | 11:18.54 |
| tor8 | I look back fondly on the days when we didn't support blend modes in MuPDF :) | 11:20.35 |
| Robin_Watts | tor8: I am thinking that redoing MuPDF's transparency support is something I can do on the beach in Tahiti. | 11:22.37 |
| tor8 | as long as you isolate the madness to a separate file!!! :) | 11:24.55 |
| Robin_Watts | tor8: I think I'd try to implement an API for 'plotters' to write the output of the scanconverter to the screen. | 11:28.27 |
| | and then we'd have 'fast' and 'slow' versions that do simple or complex blending as required. | 11:28.58 |
| | and choose between them at runtime. | 11:29.14 |
| | Gonna have a look at bug 695556 | 11:32.50 |
| Guest89926 | Hi guys, I hope this is the right place to ask this. I'm trying to print a PDF through GhostScript using these flags: -dPrinted -dNOPAUSE -dNoCancel -dNOPROMPT -dNOSAFER -sDEVICE=mswinpr2 -dFIXEDMEDIA -dPDFFitPage -sPAPERSIZE=a4 -sOutputFile=%printer%printerName | 12:12.52 |
| | I'm getting some bizarre formatting issues (sizes are wrong - too wide, not high enough and images go completely wrong) but this only seems to happen when images are present - without images the PDF prints OK | 12:13.33 |
| | have you seen anything like this before? | 12:13.41 |
| Robin_Watts | Guest89926: Do you get the same results when printing to a bitmap? | 12:13.55 |
| | say using: | 12:13.59 |
| Guest89926 | it only seems to be to one printer - printing to something like CutePDF Writer seems to not have the issue | 12:14.31 |
| Robin_Watts | -dPrinted -dNOPAUSE -dNoCancel -dNOPROMPT -dNOSAFER -sDEVICE=png16m -dFIXEDMEDIA -dPDFFitPage -sPAPERSIZE=a4 -sOutputFile=out.png | 12:14.36 |
| Guest89926 | You can see what I mean here: http://stackoverflow.com/questions/29344293/ghostscript-does-not-print-pdf-file-to-a-real-printer-correctly-but-works-fine | 12:14.39 |
| | will try bitmap now, one moment | 12:14.47 |
| Robin_Watts | oh, so Kens has looked at this already? I probably won't be able to add much. | 12:15.31 |
| Guest89926 | Oh :( ok thank you anyway | 12:15.52 |
| Robin_Watts | What version of ghostscript, btw? | 12:17.48 |
| kens | SO says 9.15 | 12:17.58 |
| Robin_Watts | so it does. sorry. | 12:18.20 |
| kens | Its a good SO report, lots of information, and screenshots. I'm only sorry I can't think of any way to see how it could happen.... | 12:18.47 |
| Robin_Watts | I'd guess that gs is outputting a bitmap fine. | 12:19.00 |
| | and that it's the "rendering the bitmap to the device context" phase which is going wrong. | 12:19.15 |
| kens | It 'should' be. And teh fact that it works with PDFWriter pseudo printers suggests there isn't anythign very strange being done. | 12:19.32 |
| | It doesn't exactly render the bitmap, it BitBlts it | 12:19.45 |
| Robin_Watts | right. | 12:19.50 |
| kens | I thi9nk, its been a while since I looked at this | 12:19.56 |
| Robin_Watts | I'd bet it's the GDI phase that's going wrong though. | 12:20.12 |
| Guest89926 | Since it seems fine without the images, I guess it's something we're doing wrong there | 12:20.19 |
| kens | But, if that were wrong, then I would expect it *always* to be wrong, and ther rporeter says it isn't, it works with some PDF files | 12:20.29 |
| Guest89926 | I'll leave Chen (my colleague whose issue it is) to experiment with that and I'll let you guys know if we get to the bottom of it | 12:20.53 |
| kens | I'm at a loss to explain how the same path can work without images, when with images fails (GS does the same thing internally after all) | 12:21.13 |
| Robin_Watts | kens: I wonder if we can get the driver to save the bitmap out before it bitblts it. | 12:21.16 |
| kens | Robin_Watts : Yes, easy enough, though we'd have to modify the device to do so I believe, I don't think it has any debugging to do that. | 12:21.45 |
| | I'll try and check after I finish my lunch | 12:21.56 |
| kens | is eating atm | 12:22.01 |
| Robin_Watts | tor8: 2 fixes on robin/master | 12:23.39 |
| Guest89926 | could the issue be anything to do with the DPI on one of the images? could it cascade onto the whole print? I don't understand why it would work for CutePDF, etc. but not for a physical printer though | 12:27.25 |
| | (Chen hasn't tried outputting to PNG yet - sorry) | 12:27.40 |
| Robin_Watts | Guest89926: CutePDF uses the pdfwrite device internally, I think. | 12:28.03 |
| | This means that we don't ever render to a bitmap. | 12:28.16 |
| kens | I can'rt see how, as the image we blit is created by GS. The only way it could be wrong is for GS to render teh image incorrectly, whcpc9-ando5-2- is suggesitng we dump the bitmap from the mswinpr2 device | 12:28.16 |
| | Robin_Watts : It does work the same way | 12:28.28 |
| | If you use mswinpr2 to send to *any* printer on windows it gets rendered to a bitmap, blitted to the DC, and then the DC is told to print it | 12:28.53 |
| Robin_Watts | kens: Oh, so CutePDF is being driven *through* mswinpr ? | 12:29.12 |
| | I assumed CutePDF was a direct wrapper for gs using pdfwrite. | 12:29.32 |
| kens | I believe that';s the way they are using it, using mswinpr2 devcie to drive a Windows printer, CutePDF appears like a printer | 12:29.40 |
| Robin_Watts | Right. | 12:29.44 |
| | That (to me) makes it sound even more like it's an error at the GDI phase. | 12:30.00 |
| kens | CutePDF (like so amny others) does indeed use GS< but it takes its input from teh WIndows printer pielien | 12:30.15 |
| | SOrry, its hard to type one-handed | 12:30.28 |
| Robin_Watts | kens: so CutePDF produces PDFs with bitmaps in, not high level object? | 12:30.38 |
| | +s | 12:30.43 |
| kens | Yes, correct, or so I understand | 12:30.47 |
| | the workflow | 12:30.54 |
| Robin_Watts | ok, very odd then. | 12:31.00 |
| Robin_Watts | decides to try this "lunch" idea of kens... | 12:31.15 |
| Guest89926 | Hmm, ok. Without the means to test myself I can't really add anything to our question at the moment so I'll get Chen to play around and come back if we have any questions. | 12:31.32 |
| kens | recomends not eating it at the keyboard | 12:31.34 |
| Guest89926 | Thank you so much for your help guys :) | 12:31.38 |
| kens | NP | 12:31.44 |
| chrisl | kens: I wonder if that's the same problem (or related) someone popped up with a couple of months ago, with mswinpr2.... that we worked around by setting the resolution and page size explicitly on the command line.... | 12:43.49 |
| kens | chrisl err possibly, I don't recall the incident.... | 12:44.08 |
| | was it on irc ? | 12:44.27 |
| chrisl | Yeh, it was - I found a comment in the source: | 12:45.20 |
| | /* This driver uses the printer default size and resolution and | 12:45.26 |
| | * ignores page size and resolution set using -gWIDTHxHEIGHT and | 12:45.26 |
| | * -rXxY. You must still set the correct PageSize to get the | 12:45.26 |
| | * correct clipping path. | 12:45.26 |
| | * The code in win_pr2_getdc() does try to set the printer page | 12:45.27 |
| | * size from the PostScript PageSize, but it isn't working | 12:45.27 |
| | * reliably at the moment. | 12:45.27 |
| kens | ah yes, I recall that now. I'll go post that on the SO thread and see if it helps. THanks chrisl | 12:45.48 |
| chrisl | NP - it only just occurred to me..... | 12:46.07 |
| | If the Postscript world is seeing the "wrong" page size, I could see the PDFFitPage code possibly causing the kind of distortion seen there | 12:50.27 |
| kens | Yes, its kins od possilbe, I'm just writing something now. | 12:50.47 |
| henrys | does anyone know if our now cyrillic coverage is as good as the free open source font coverage? | 13:49.08 |
| tor8 | Robin_Watts: I only see one (the _NET_WM_NAME addition) | 13:53.23 |
| | which LGTM | 13:53.26 |
| Robin_Watts | tor8: there will be 2 more in a mo. | 13:53.54 |
| chrisl | henrys: we're probably not as good as the Droid fonts, and probably not as good as the noto fonts. | 13:59.42 |
| Robin_Watts | tor8: 2 more there now. | 14:01.33 |
| | mvrhel_laptop: Hey. Did you get a chance to look at bug 695861 ? | 14:04.50 |
| tor8 | Robin_Watts: it seems to me like there are a lot of places the compression params get converted to and from pdf_obj to fz_compression_params structs | 14:05.39 |
| | with a lot of similar looking duplicated code | 14:05.46 |
| Robin_Watts | 2 places, I think. | 14:05.47 |
| | build_filter and the new code. | 14:06.25 |
| | I couldn't immediately see a way to common them up. | 14:06.40 |
| tor8 | pdf-op-buffer, pdf-stream and pdf-device | 14:07.04 |
| | but I guess they look different enough to not worry | 14:07.14 |
| | so now we have 2 copies of each reading and writing them | 14:07.38 |
| Robin_Watts | there are 2 places where they are 'packed' (the 2 I just listed) | 14:07.49 |
| | and 2 places where they are 'unpacked'. | 14:07.56 |
| | 3 places where they are unpacked. | 14:08.18 |
| tor8 | oh, 3 places? | 14:08.31 |
| Robin_Watts | but each of those 3 places is in a different implementation of the interface. | 14:08.38 |
| tor8 | ah, right, 1 where they are applied as well | 14:08.48 |
| Robin_Watts | pdf-op-buffer, compressed-buffer and pdf-device. | 14:08.53 |
| tor8 | for the actual decoding | 14:08.57 |
| Robin_Watts | yeah | 14:09.05 |
| tor8 | we could refactor send_image and the op-buffer stuff into one function, and call pdf_print_object to write it out in the "BI" operator | 14:09.36 |
| | but as long as we don't anticipate adding more formats to it (and I sure hope we don't) then I don't see it as a problem requiring fixing | 14:10.29 |
| Robin_Watts | tor8: yeah, I'd favour leaving it as is. | 14:10.50 |
| tor8 | but if there is an elegant way to make the packing/unpacking common I'd go for it | 14:10.56 |
| Robin_Watts | Unless you can see a particularly neat way. | 14:11.02 |
| tor8 | can_reuse_buffer and build_filter could probably both use a function build_shortstop_filter() which has the common params packing | 14:13.36 |
| | the "we will shortstop here" chunks | 14:13.57 |
| Robin_Watts | tor8: Yes, but then build_filter would need to reread some of the params to actually open the filters. | 14:14.06 |
| | which didn't appeal to me. | 14:14.13 |
| tor8 | you could read the params from the compressed_params struct? | 14:14.32 |
| Robin_Watts | Not in the case we don't have a compressed params struct. | 14:14.47 |
| tor8 | we could make sure we always do, but I see what you mean | 14:15.08 |
| Robin_Watts | Hmm. | 14:15.16 |
| tor8 | if (params != local_params) return chain; else fz_open_faxd(params->u.fax.k) etc | 14:15.36 |
| Robin_Watts | If we always had a struct, and we always got it filled in, then we could always open the filters using it. | 14:15.38 |
| | and we might be able to reuse that code with the other place that opens filters from the struct. | 14:16.06 |
| | I will give that a go in a moment. | 14:16.27 |
| | tor8: You happy with the matrix inversion change? | 14:21.49 |
| tor8 | not terribly, but matrix inversion is a tricky business | 14:29.26 |
| Robin_Watts | tor8: I'm just doing the intermediate maths in doubles rather than floats. | 14:33.40 |
| | The problem is that we have a ctm that's got values like 0.000000017 in it. | 14:34.13 |
| | inverting that in floats means the determinant ends up < FLT_EPSILON. | 14:34.42 |
| | inverting it in doubles means it stays larger than DBL_EPSILON. | 14:34.59 |
| tor8 | Robin_Watts: yeah, I understand the problem and the solution. it irks me that we need doubles, but I think it's the right choice | 14:50.35 |
| kens | Its a dumb PDF file, but it is valid.... | 14:50.59 |
| Robin_Watts | tor8: Yeah, at least we don't need to *store* doubles anywhere in our persistent data. | 14:51.19 |
| kens | Congrats ongetting the release out chrisl | 14:56.45 |
| chrisl | Cheers - managed it (just) in March :-) | 14:57.22 |
| kens | :-D | 14:57.28 |
| chrisl | Hopefully I can now finish setting up my new PC...... | 14:58.27 |
| henrys | chrisl: what did you end up getting? | 14:59.45 |
| chrisl | henrys: I specced up an i7 from quietpc.com - following Joseph's recommendation | 15:00.21 |
| | henrys: the base spec I started from was: http://www.quietpc.com/sys-a430 | 15:01.16 |
| Robin_Watts | tor8: refactored version on robin/master. What do you think? | 15:01.39 |
| henrys | chrisl: nice. the prices are better than I thought too. | 15:02.33 |
| chrisl | henrys: remember that's ukp not usd! | 15:03.12 |
| henrys | chrisl: yeah I know. | 15:03.39 |
| chrisl | But yeh, I'm pleased with it. I'll almost certainly go for something similar when I replace my personal machine | 15:04.00 |
| Robin_Watts | chrisl: Largest PSU option is 500W :( | 15:05.56 |
| chrisl | Robin_Watts: that's plenty, really | 15:06.33 |
| kens | wonders if Robin_Watts is htinking of big graphics cards | 15:06.52 |
| Robin_Watts | is | 15:06.59 |
| kens | But they won't be quiet anyway will they ? I thought they all came with big fans these days | 15:07.24 |
| chrisl | But then, fewer spinning disks mean less power in the the storage department | 15:07.29 |
| Robin_Watts | My existing graphics card pulls 285W under load. | 15:08.07 |
| | It has 2 big fans on, so is pretty quiet in normal use. Spins up when I play games, but then... explosions! | 15:08.36 |
| chrisl | They do bigger PSUs in other cases, but I don't think they are silent, I think the bigger PSUs all have fans | 15:09.31 |
| Robin_Watts | chrisl: Yeah, I'd be happy with a quiet rather than a silent machine. | 15:09.57 |
| tor8 | Robin_Watts: I have an nVidia Twin Frozr GTX 660. dead silent, even when playing games. except for once every two months when it decides to act up and spin the fans at 100% ... until I blow the dust away :) | 15:10.34 |
| Robin_Watts | yeah, I have the same thing, but a 560Ti. | 15:10.54 |
| chrisl | I just don't need a really big PSU, not being a gamer..... the 680, 730 and 750 watt PSUs all have fans in them. | 15:11.04 |
| tor8 | chrisl: my PSU is a fanless seasonic X400... which is just the 750 watt one but without the fan | 15:11.55 |
| Robin_Watts | Interesting. The 980s claim a graphics card power of 165W. | 15:12.43 |
| | Even the titans claim "just" 250W | 15:13.22 |
| | For a 250W graphics card, they recommend a 600W PSU. | 15:13.43 |
| tor8 | Robin_Watts: I suspect they recommend bigger ones than you actually need, because most stock PSUs are so crap they can't deliver anywhere near their rating :( | 15:14.40 |
| Robin_Watts | tor8: maybe. | 15:15.03 |
| tor8 | and a flaky PSU is quite likely to make the motherboard act funny and give you lots of bluescreens | 15:15.30 |
| Robin_Watts | is still running a Core Quad 2 system. Haven't found any games that need more than that for 1920x1200 playing yet. | 15:15.45 |
| henrys | Intel is making huge progress on integrated GPU's, just from reading there are a lot of playable games with Iris. | 15:24.38 |
| | apple is probably pushing that... one port and one chip for the next generation. | 15:26.49 |
| Robin_Watts | sizeof(GPU) >> sizeof(CPU) these days, right? | 15:31.01 |
| | Certainly for ARMs. | 15:31.15 |
| | 2.2billion transistors in an size core i7. 8.1 billion in the latest nvidia GPU. | 15:33.25 |
| | ARM Cortex-A9 has just 26 million. | 15:34.48 |
| | My first ARM had just 25000 in. | 15:35.05 |
| henrys | yeah but what do you need you just said your system runs everything you want. | 15:35.08 |
| | ? | 15:35.09 |
| | http://us.hardware.info/reviews/4776/16/intel-iris-pro-5200-graphics-review-the-end-of-mid-range-gpus-the-elder-scrolls-v-skyrim-1920x1080 | 15:35.36 |
| Robin_Watts | henrys: My point is that putting a CPU on the side of a GPU is probably no big deal these days. | 15:35.40 |
| | cos the power/io/die size/coling requirements for the CPU are all dwarfed by the GPUs. | 15:36.14 |
| henrys | probably matters on laptops and mini stuff where board space is at a premium I would think the integrated CPU would take up less room, but not sure. | 15:37.21 |
| Robin_Watts | henrys: Yes, a single chip solution like that is going to be very attractive. | 15:37.50 |
| | Even the Raspberry pi has the CPU on the GPU. | 15:38.01 |
| | I idly looked at laptops last week. | 15:38.30 |
| | DELL are doing a 13 inch with a quad HD screen for less than a grand. | 15:38.47 |
| kens | Did you look at the 'new' Macbook air ? Its supposed to have a > 7 hour battery life | 15:38.58 |
| Robin_Watts | kens: I did not. | 15:39.12 |
| | If I was spending silly money on a laptop, the DELL XPS15 would probably be my choice at the moment. | 15:39.47 |
| kens | http://www.theregister.co.uk/2015/03/30/review_apple_macbook_air_13_inch_early_2015/ | 15:39.51 |
| | BUt yes, its very expensive for what it is | 15:40.00 |
| Robin_Watts | The DELL is cheaper than the macbook pro and has nicer specs. | 15:40.20 |
| | and claims a 7 hr + battery life. | 15:40.37 |
| kens | Hmm, even better | 15:40.43 |
| henrys | I started looking into it because I wanted an NUC but I do play a game once in a while... the newer ones ship with iris so it looks like it would be okay. | 15:41.00 |
| Robin_Watts | NUC ? | 15:41.18 |
| kens | Hmm, I wonder if you can turn off the touch screen...... | 15:41.32 |
| | Oh and I'd have to upgrade it to Windows 7 as well :-) | 15:41.57 |
| Robin_Watts | Next Unit of Computing, right. | 15:41.59 |
| | I suspect the XPS15 is too large to work with on an economy seat in a plane. | 15:42.27 |
| kens | I was just wondering that, I have trouble with mine | 15:42.36 |
| Robin_Watts | The XPS13 sounds like it would be ideal for that. | 15:42.59 |
| | It's a 13 inch screen in the space typically taken by an 11 inch laptop. | 15:43.22 |
| kens | Developer edition comes wiht Linux :0) | 15:43.27 |
| Robin_Watts | cos they've removed the bezels. | 15:43.30 |
| rayjj | I've got a Dell XPS L511Z and I STRONGLY recommend that you avoid that one (really piss poor design) | 15:43.32 |
| Robin_Watts | I don't really believe a 3800xwhatever screen is justified on a 13" laptop though. | 15:43.51 |
| kens | I'd have to increase the size of everything to read it | 15:44.12 |
| rayjj | it's a 15.6" screen and it doesn't work very well on an economy seat | 15:44.27 |
| Robin_Watts | and the battery on the XPS13 is 2/3 of the size of the XPS15. | 15:44.27 |
| kens | ah its 1920x1080 | 15:44.31 |
| Robin_Watts | kens: The base spec screen is 1920x1080 | 15:44.42 |
| kens | yes that's what I was looking at | 15:44.53 |
| Robin_Watts | the 3800x2160 is an upgrade. | 15:44.56 |
| kens | Yes, and I'm sure I'd be unable to read text on it :) | 15:45.17 |
| henrys | they are still quite expensive relative to performance but look at the size of these things: http://arstechnica.com/gadgets/2014/01/smallness-uber-alles-intels-tiny-haswell-based-nuc-desktop-reviewed/ | 15:45.58 |
| kens | Looks pretty similar to a Pi in terms of size | 15:47.14 |
| chrisl | henrys: I'll probably get one of those when the Mac Mini in my living room needs replaced..... decent value, too | 15:47.19 |
| Robin_Watts | henrys: That would be attractive as a steam box *if* they have good enough graphics power. | 15:47.31 |
| kens | Its Intel graphics integrated | 15:47.54 |
| | So I'd be doubtful | 15:48.06 |
| rayjj | The XPS 15 looks like the same case design as mine, which is REALLY bad. | 15:48.22 |
| Robin_Watts | rayjj: why? | 15:48.40 |
| | kens: All the xps13's are integrated graphics. The xps15 has nvidia as an option. | 15:49.30 |
| | I looked at the alienwares too, but they don't have a swappable battery :( | 15:49.51 |
| kens | : I don't really play game son my laptop much | 15:49.55 |
| Robin_Watts | kens: Nor do I, but I'd like to have the option when on holiday/on flights. | 15:50.18 |
| rayjj | it's Al and it had a cheesy strip around the KB edge that kept getting nicked up (some kind of metal), and little spikes would catch on my shirts and pull threads. Then the bottom feet rubber parts broke loose leaving hard plastic. | 15:50.20 |
| | Opening the case is MUCH harder than it needs to be (to change out the HD or replace the battery or clean the fan) and some plastic parts along the connector side have lost bits (possibly due to weakening during disassembly) | 15:51.48 |
| | I took the trim strip off and now it just looks funky, but at least it doesn't damage my clothes. | 15:52.34 |
| | Dell was totally unresponsive to the problem, so I doubt they've fixed it. | 15:52.57 |
| | The screen has one line of pixels along the left edge that failed and is always solid yellow. This is the first time I've had an LCD problem that is worse than a single stuck pixel | 15:54.06 |
| | My next laptop *might* be a dell, but they've definitely gone down hill (this is my fourth one). I also will prefer a model that has a battery I can swap out, but that isn't a stopper for me) | 15:55.55 |
| henrys | rayjj: a missing line of pixels is grounds for return, no? or did that happen past warranty? | 16:00.28 |
| rayjj | henrys: it was past warranty (which was just 1 year). In the past I got a three year extended warranty, but Dell didn't offer it on this model (I guess they knew something). Their factory warranty used to be 3 yrs when I bought my first high end Dell laptop | 16:07.09 |
| Robin_Watts | tor8: More fixes on robin/master | 16:16.20 |
| | tor8: I'll squash the refactor in before committing, but it's probably easier to review like this. | 16:17.08 |
| tor8 | Robin_Watts: the returns at the end of each block in the if-else chain are unneccessary | 16:26.19 |
| | and I'm confused about the final return from can_reuse_buffer | 16:27.00 |
| | but maybe I'm just confused about can_reuse_buffer altogether :) | 16:27.35 |
| | Robin_Watts: there's a minor tweak on tor/master to remove a warning introduced by the x11 waitpid change | 16:28.01 |
| Robin_Watts | can_reuse_buffer returns true, if the buffer is uncompressed, or shortstoppable. | 16:28.10 |
| | hence we call build_compression_params, and if it fails to recognise the image type, we return false. | 16:28.41 |
| tor8 | ah! there's the earlier test for whether it is compressed at all. | 16:29.40 |
| | LGTM, modulo the no-op returns | 16:30.43 |
| Robin_Watts | Ta. | 16:33.21 |
| | And the other commits? | 16:33.28 |
| tor8 | Robin_Watts: all good | 16:34.33 |
| Robin_Watts | Ta. | 16:34.37 |
| | 1 more on robin/master then. | 16:38.13 |
| tor8 | Robin_Watts: really, shift-space? | 16:41.26 |
| | is that a standard keybinding somewhere? | 16:41.37 |
| Robin_Watts | tor8: yeah. the use of shift to reverse things is typical. | 16:41.44 |
| | tab vs shift-tab etc. | 16:41.49 |
| tor8 | huh. it works in firefox! | 16:41.54 |
| | I guess it looks reasonable as well then | 16:42.06 |
| Robin_Watts | Ta. | 16:42.11 |
| chrisl | hi fredross-perry | 17:05.10 |
| fredross-perry | chrisl: yo | 17:05.30 |
| chrisl | I gave the GSView for 32 bit linux a whirl. The only immediate problem was going to the print dialog crashed it | 17:06.09 |
| | Happened on the 64 bit one, too... | 17:06.31 |
| fredross-perry | thanks, Iâll check that out. | 17:07.12 |
| chrisl | I should have a bit more time this week, so I'll keep using it | 17:07.59 |
| fredross-perry | do you mean, simply displaying the print dialog? Or doing something with the dialog? | 17:08.33 |
| chrisl | Just doing File->Print segfaulted | 17:09.04 |
| fredross-perry | ok thanks | 17:10.27 |
| henrys | Robin_Watts, fredross-perry maybe a little picky here but that last commit message - from fred by Robin_Watts ... ?? | 17:35.47 |
| fredross-perry | sorry, where? | 17:36.07 |
| henrys | http://git.ghostscript.com/?p=mupdf.git;a=commit;h=0af0f0f0740fc4914c4c13e232f88b8304173c76 | 17:37.13 |
| fredross-perry | the bug report has more detail in it. | 17:40.02 |
| henrys | fredross-perry: fair enough that sort of commit message raises a flag and I was worried about it. | 17:41.53 |
| fredross-perry | is it desireable/easy to edit the message to make it clearer? | 17:42.28 |
| Robin_Watts | I think the length of the commit message is commensurate with the length of the patch. | 17:43.01 |
| | And the details required are in the bug report. | 17:43.14 |
| | fredross-perry: We cannot edit the commit message once it's gone to golden. | 17:43.47 |
| fredross-perry | I see. | 17:43.58 |
| Robin_Watts | I thought the commit message was fine. Tor reviewed it and passed it, so presumably thought it was fine too. | 17:44.21 |
| fredross-perry | chrisl: the print dialog crashes when it canât find any available printers. Iâll issue a fix shortly. | 17:57.21 |
| henrys | fredross-perry, Robin_Watts : the uri rfc say no colon there 3.3 (Path) do we want to create the file anyway? | 18:01.29 |
| chrisl | fredross-perry: hmm, odd, I have printers installed.... that could indicate another bug, or an incompatibility with the cups on here.... | 18:02.46 |
| | have to head off...... | 18:03.21 |
| fredross-perry | actually not using CUPS at this time. So it might be a Qt bug or limitation. | 18:03.23 |
| chrisl | Oh, okay. Well, I'll give it whirl when you have something | 18:03.53 |
| henrys | Robin_Watts: the duck has not left Maggie's side for hours. thanks! | 18:11.28 |
| fredross-perry | chrisl: new builds, give it a try. Youâll probably get a âno printersâ message, but it shouldnât crash. | 18:25.37 |
| Robin_Watts | henrys: Ah! It arrived :) | 18:42.30 |
| | henrys: I don't follow about the URI thing. | 18:43.12 |
| | This is MuPDF being asked to open a file under android. | 18:43.23 |
| | so we need to cope with whatever is thrown at us. | 18:43.55 |
| | presumably the URI might be coming to us as file://localhost/usr/sdcard/Documents/a%34d | 18:44.34 |
| | (or whatever hex value : is) | 18:44.44 |
| fredross-perry | I get that the â:â violates the URI spec. But AFAIK, muPDF is not creating the file, the user is. The fix is just making sure muPDF does not crash when trying to open the file. | 19:00.44 |
| Robin_Watts | fredross-perry: yeah. | 19:01.50 |
| henrys | so then why use getEncodedPath() at all?, the code implies we want a vailid uri. That's why I thought we cared. | 19:03.56 |
| Robin_Watts | Well, you would expect 'getEncodedPath' to give you something that when 'decoded' was a valid path. | 19:07.29 |
| | because URIs are supposed to be able to properly encode all ascii chars. | 19:07.51 |
| | (so you'd expect the encoded path to use %69 or whatever. | 19:08.08 |
| | Given that uri.toString works in some cases when the other one doesn't, you'd have to think there is a bug in android. | 19:09.00 |
| | and in the absence of every android version to test here, using belt and braces seems a reasonable approach. | 19:09.34 |
| | Try the thing that *should* work, and if that doesn't work, try the thing that seems to work in some cases. | 19:09.53 |
| henrys | just reading the default My Files app won't read files with ":" it greys them out. The only thing I' | 19:11.17 |
| | d worry about it s security issue we aren't noticing other than that no big deal. | 19:11.36 |
| mvrhel_laptop | ok so I think I have all the issues that ken had found with gsview figured out except the problem with my gsprint.dll. I am able to duplicate this issue on my x86 win7 machine. setting up remote debug now to figure out what is going on | 19:12.18 |
| Robin_Watts | mvrhel_laptop: did you have a chance to look at that mupdf bug? | 19:12.56 |
| mvrhel_laptop | Robin_Watts: no not yet | 19:13.07 |
| Robin_Watts | ok. | 19:13.10 |
| mvrhel_laptop | I will look at it this week | 19:14.24 |
| Robin_Watts | mvrhel_laptop: I've watched the first 3 Black Mirror, now. | 19:22.40 |
| | The first one... wow... | 19:22.44 |
| mvrhel_laptop | hehe | 19:22.56 |
| | you brits have a sick mind | 19:23.05 |
| | I have to say, there is not much that leaves me in shock on tv. that was one thing that did though | 19:24.01 |
| | off to grab lunch. bbiab | 19:24.17 |
| henrys | mvrhel_laptop: I was thinking good thing thatcher wasn't in office... | 19:24.44 |
| mvrhel_laptop | ha! | 19:27.48 |
| fredross-perry | stepping out ⦠| 19:41.02 |
| | steppin in... | 20:04.57 |
| | chrisl: do lpstat -p -d and tell me what you get. | 20:14.07 |
| pipitas | The latest Git sources have "gs/doc/History9.htm" where the release date of 9.16 as given in top ToC being (2014-09-22) (same as for 9.15) | 20:35.45 |
| fredross-perry | chrisl: new builds (just now) that should fix the issue wherein you could not see your printer. | 22:19.57 |
| Robin_Watts | OK, I'm uploading a pdf file to http://ghostscript.com/~robin/WhyAmIBroken.pdf | 23:22.56 |
| | I'd be interested if anyone can tell me why it's broken. | 23:23.08 |
| | It's pdf_reference17.pdf with 1 change made to it and it saved incrementally. | 23:23.30 |
| | The last 2 objects in the file are the changed object and a new xref stream. | 23:23.54 |
| | gs and mupdf both process it without question. | 23:24.02 |
| | Acrobat loads it fine, but offers to save a fixed version on close. | 23:24.22 |
| | What is acrobat objecting to? | 23:24.30 |
| | If you strip the last 2 objects off in an editor, you get back to the original file, and it works fine. | 23:25.01 |
| sebras | cd /tmp | 23:26.16 |
| | ehm... | 23:26.21 |
| Robin_Watts | upload complete. | 23:28.30 |
| | sebras: hehe. | 23:28.36 |
| | Forward 1 day (to 2015/03/31)>>> | |
IRC Logs