| | <<<Back 1 day (to 2013/03/06) | 2013/03/07 |
| ray_laptop | glad to see that Graeme Gill is pro-Ghostscript when it comes to our color management. | 01:50.52 |
| | IMHO, mvrhel needs to make sure to objectively critique anything that folks that do Poppler try to come up with to cadge in color management. It's likely to have MANY holes | 01:52.03 |
| | Robin_Watts: tor8: paulgardiner: (for the logs) we probably need to get a reading on the 'viewer' comment passed along by tkamppeter from the OpenICC group (email forwarded to tech) | 01:54.12 |
| tkamppeter | chrisl, hi | 08:15.39 |
| chrisl | tkamppeter: hi | 08:17.29 |
| tkamppeter | chrisl, you have probably also seen the discussion which I have initiated on OpenICC. Ghostscript and Poppler have both their advantages and disadvantages. | 08:18.54 |
| chrisl | tkamppeter: some of it | 08:19.17 |
| tkamppeter | chrisl, GS has the much better Color Management, and therefore I will continue to use it on the desktop form factor. On the mobile carrying both GS and Poppler would be too much and there is no color management and no app sending PostScript, so Poppler is a nice low-footprint solution. | 08:21.16 |
| chrisl | tkamppeter: even with poppler (and no color management), converting PDF to Postscript is going to be a tall order for a low resource device | 08:22.51 |
| kens | thinks a former project would work well :-) | 08:23.18 |
| tkamppeter | chrisl, one big problem of GS, independent whether desktop or mobile, is the compatibility with buggy PS printers. Poppler's PostScript simply works on these printers but GhostScript needs a lot of fixing, you know it. | 08:24.13 |
| chrisl | tkamppeter: that's life - I'm still of the opinion that poppler probably went through a similar process when it's PS output was rolled out. | 08:25.12 |
| tkamppeter | chrisl, should one not perhaps investigate how Poppler's PostScript is structured and try to make Ghostscript's PostScript output similar? | 08:25.31 |
| kens | tkamppeter no guarantee it works on all systems either | 08:25.49 |
| chrisl | tkamppeter: poppler's PS output is structured very similarly to ps2write's - the overall structure is not the issue | 08:26.16 |
| tkamppeter | chrisl, but what makes the difference that Poppler's PS works so well with the printers and GhostScript's not? | 08:27.03 |
| chrisl | tkamppeter: I would assume because they have been through the process of tracking down all these corner cases that cause problems with these sh*t printers | 08:27.49 |
| kens | We *could* produce simpler code, but in at least one case that would cause a group of printers to print more slowly | 08:28.50 |
| tkamppeter | chrisl, would it then perhaps make sense to go through Poppler's source code to find their PS-printer-bug quirk rules and implement these in Ghostscript? | 08:29.20 |
| chrisl | tkamppeter: sure, go ahead | 08:29.33 |
| kens | tkamppeter if you can identify where poppler output is tailored for a specific printer bug I would be interested to know how you identified it! | 08:30.05 |
| tkamppeter | kens, does it mean that Poppler prints reliably on most printers but for the price of making the printers printing slowly? | 08:30.16 |
| kens | tkemppeter, the case I have in mind was the limited number of 'bind' operations | 08:30.43 |
| | The poppler code squeaks in under the limit, ours doesn't | 08:30.59 |
| | By removing the bind we get our code to work | 08:31.08 |
| chrisl | kens: I have no confidence any "simplified" PS we implemented wouldn't trip over problems, given some of the problems we've found so far | 08:31.12 |
| kens | At the cost of performance. | 08:31.14 |
| | chrisl Agreed and what I was about to say was that in time its likely that the poppler output will trip over this 'bind' problem as well | 08:31.41 |
| chrisl | Hmmm, poppler's bugzilla doesn't have a pdftops component :-( | 08:32.19 |
| kens | We could address one or two f the parcitular problems that have cropped up (filter chains are one) but disallowing the use of the (highly efficient) G4 fax filter just because one printer has a broken implementation when its used in a fontis unreasonable | 08:33.30 |
| chrisl | Grr, and their bugzilla only seems to go back to 2011..... | 08:34.05 |
| kens | Quickly reviewing the clases of bugs we could adress them all with varying degrees of difficutly. THe bind problem is probably the hardest to address (and the most unreasonable limit) | 08:36.00 |
| | But there is no reason to think these are the only ones | 08:36.14 |
| tkamppeter | chrisl, Poppler bugs are handled at https://bugs.freedesktop.org/, product: poppler. pdftops probably falls into the "utils" component there. | 08:36.15 |
| chrisl | tkamppeter: yes, I found that - but as I said, they only seem to go back to 2011, which ain't much help | 08:36.45 |
| tkamppeter | chrisl, you have probably looked into an old Bugzilla which they have given up in favor of Freedesktop. | 08:37.02 |
| | chrisl, you mean you want to see bug reports older than 2011? | 08:37.41 |
| chrisl | Yes | 08:37.47 |
| kens | Try bug #5946 'Poppler produces broken postscript' | 08:37.50 |
| chrisl | Aha! | 08:38.19 |
| kens | 13955 " pdftops generated postscript file makes printers crash! " | 08:38.26 |
| chrisl | "both Ghostscript and Adobe Reader produce PS that prints fine" :-) | 08:39.08 |
| kens | Using 'poppler' and 'PostScript' as my search criteria I see 89 bugs | 08:39.30 |
| | THIs isn't to say that pdftops is bad, but it does serve, I think,to show that a similar process has gone on with Poppler | 08:41.41 |
| | Bug 54317 seems amusing too the first comment from the poppler people is "I sincerely think you should contact Brother developers not us. As far as i can tell that's perfectly valid postscript. | 08:42.53 |
| | If someone can prove us wrong i'd be happy to fix it." | 08:42.54 |
| | I'm pretty sure the Brother printer was one of the ones giving us trouble | 08:43.17 |
| chrisl | Sounds familiar..... | 08:43.18 |
| tkamppeter | chrisl, you told earlier that PDF->PS conversion is a high workload for a mobile device. Would it make sense that if a PS printer also supports PCL 5c/e (most do) to send PCL to the printer to lower the mobile device's workload? | 08:44.03 |
| kens | No many PS printers don't support PCL | 08:44.22 |
| | You owuld also have to renbder the whole page in the device's memory which is probably a problem | 08:45.02 |
| | (same for transparent PDF of course) | 08:45.18 |
| chrisl | tkamppeter: the issue is the same, possible worse! The problem is converting between imaging models is always complex and potentially time consuming - the greater the difference between the imaging models, the worse the problem. | 08:45.19 |
| tkamppeter | kens, I would not send PCL to a PostScript printer without checking that it supports PCL, but if a printer supports both, would prefering PCL be of help for mobile devices? | 08:45.47 |
| kens | tkamppeter, I think not no | 08:45.59 |
| | the conversion problem of PDF->PCL is harder than PCL->PS | 08:46.11 |
| | Sorry PDF->PS | 08:46.16 |
| chrisl | tkamppeter: the best solution would be don't start from PDF....... | 08:46.23 |
| tkamppeter | chrisl, kens, should one perhaps tell tyhe app SDK folks that apps should send a standard raster format, like PWG Raster as print job format? | 08:47.44 |
| kens | Note that any PDF file involving transparency, converted to non-PDF< will have to be handled by rendering to an image, which uszes lots of memory. Since Cairo-produced PDF files *always* seem to incluide transparency, this is likely to be a problem. | 08:47.44 |
| | tkamppeter, you still have to render the image at the printer resolution | 08:48.05 |
| | Not a problem for tablets (probably) but more likely a problem for current phones | 08:48.34 |
| | Not sure how much memory these have, or their processor speed | 08:48.46 |
| chrisl | tkamppeter: that might be a solution. Another solution would be to force the apps to send a subset of PDF, like PDF/X | 08:49.00 |
| kens | PDF/X-1 :-) | 08:49.14 |
| | Make sure no transparency is involved | 08:49.23 |
| kens | suspects people won't like that idea | 08:49.48 |
| chrisl | Well, PDF/X-1 is "like PDF/X" ;-) | 08:49.59 |
| | The first step would mean cairo fixing its PDF output! | 08:50.22 |
| tkamppeter | kens, chrisl, iOS devices are capable of printing out of nearly every app. It can send PDF, JPEG, or the proprietary URF Raster format. | 08:50.24 |
| kens | you have top be careful PDF-X3 (or possibly X4) allows transparency | 08:50.24 |
| | tkamppeter : iOS has a built-in renderer | 08:50.48 |
| | Let me finish the maths. | 08:50.54 |
| | a A4 page at 600 dpi CMYK Is 135 Mb | 08:52.45 |
| | As long as you have that amount of memory free you can render to a bitmap at reasonable printer resolution | 08:53.09 |
| | Chris and I came up with some ways to reduce that in a former occupation | 08:53.37 |
| | At the cost of performance obviously | 08:53.46 |
| | So its not unreasonable for a modern smart phone to be able to render the output and send a bitmap to the pritner | 08:54.18 |
| | I have no way to know how long it would take, since it depends on the processor | 08:54.32 |
| tkamppeter | kens, what do you mean with "iOS has a built-in renderer"? A piece of software which renders? In the Ubuntu mobile device this would be one of GS or Poppler, so Ubuntu Touch would also have a renderer. Or do you mean a hardware renderer in the GPU? | 08:55.06 |
| kens | tkamppeter : PDF is the native graphics format for iOS so it *has* to be able to render it, for the display if nothing else.... | 08:55.50 |
| | AFAIK its software | 08:56.05 |
| | iPhones don't have any real shprtage of memory, and decent processors | 08:56.35 |
| tkamppeter | kens, probably Android does not offer printing as it is alo used on cheapo phones with single-core and 512 MB of RAM. | 08:58.52 |
| kens | tkamppeter : I guess that's possible, I'm not really clued up on modern mobile devices. But I woulod have thought 512Mb would be enough. The porr processor would be more of a problem | 08:59.45 |
| chrisl | tkamppeter: as you've probably realised there is no single "right" answer - whatever you end up doing will be a compromise of some sort...... | 08:59.57 |
| tkamppeter | kens, for me it looks like that Ubuntu Touch, as it is starting now, will be aimed to higher profile phones. | 09:00.14 |
| kens | tkamppeter : then I would say you have a wider range of choices | 09:00.30 |
| | You probably have the horsepower to render to bitmap, or convert to POostScript, or PCL, or (ROFL) XPS | 09:01.01 |
| | Personally I would think it better to convert to PostScript for a PostScript printer, but you can argue about such decisions endlessly | 09:02.32 |
| tkamppeter | kens, if we would support the cheapo sector, one could even think about doing things like checking the hardware horsepower and print only in 300dpi on lower-end phones. | 09:03.04 |
| kens | tkamppeter : yes that would make some sense, that wold work on btoh PCL and PS pritners, with the upscaling done in the printer (if required) | 09:03.49 |
| | The oujtput might not be quite as good, but it should be pefectly acceptable. THat wiould of course lower the memory requirement by 4 | 09:04.26 |
| | You might also consider printing in gray scale, which would drop the requirement by another 4 | 09:04.42 |
| chrisl | tkamppeter: going back to the Ghostscript vs poppler discussion: it does seem that poppler went through a similar process of finding workarounds for dodgy printers, but I'm not sure that their experience helps us much. Although the general structure of the Postscript is very similar, the implementation details are quite different. | 09:05.11 |
| tkamppeter | chrisl, so I will continue forwarding printer incompatibility bug reports to you and let you investigate them with the users. | 09:09.55 |
| kens | Sadly I can't see any other way of dealing with these, we don't have the printers, and it needs one of us to determine the problem by working through the PostScript :-( | 09:10.33 |
| chrisl | tkamppeter: I think that's best. I will take a look through the poppler bugzilla and git repo for any hints, but, like I said, I'm not hopeful. And the code is not well commented about this type of issue :-( | 09:11.13 |
| tkamppeter | chrisl, I will keep GS for pdftops on the desktop then. On mobile we can naturally carry only one of GS and Poppler, due to space reasons. PCL printing on PostScript printers could perhaps be used for more reliable driverless printing on mobile (fully automated printer setup without PPD file/driver collection on the device). | 09:14.00 |
| chrisl | tkamppeter: for mobile devices, it would also be worth looking at including support for printers that support printer PDF directly, thus avoiding the need for conversion at all..... | 09:15.11 |
| tkamppeter | chrisl, this I already take into account. If a printer tells that it supports PDF, I let the PDF being pased onto the printer, without conversion, Cairo killing the printer directly. | 09:16.35 |
| | chrisl, ...instead of the battery of the mobile device. | 09:17.05 |
| chrisl | :-) | 09:17.13 |
| | tkamppeter: FWIW, the biggest single difference between ps2write and pdftops output is that the latter can produce Level 3 PS, and ps2write (obviously) only produces Level 2. We have wanted add a ps3write implementation for quite a while, but we've never had the time :-( | 09:18.07 |
| kens | Maybe I cna persuade Henry its a good idea at the staff meeting | 09:18.34 |
| chrisl | kens: Well, the simple fact is, we (you!) have genuinely more important stuff to do.... | 09:19.17 |
| kens | Oh GOd I hate WIndows 8..... Where ahve they hiddent eh control panel :-( | 09:20.11 |
| chrisl | Skegness? | 09:20.32 |
| kens | I seem to remember there's a spot I can click, but of course I can't find it because.... its not marked... | 09:20.55 |
| chrisl | kens: maybe time for one of the third party shells? | 09:21.26 |
| kens | I think so... | 09:21.35 |
| | Google first | 09:22.02 |
| | Got it, you have to start from teh stupid screen, not the desktop | 09:24.17 |
| chrisl | tkamppeter: FWIW, most of the users with printer problems have been pretty good helping us track them down - I've had one user "go dark" and just stop responding, and one that was, frankly, just too stupid for me to keep working with...... | 09:24.28 |
| nilli | I've run into an issue where I can run a gs script just fine from terminal but when I try to run the exact same script from php I get the error message "Unable to open the initial device, quitting". It's not a permission problem, but I think I've narrowed it down to an environment problem. | 10:09.19 |
| | some guy using Java on AIX figured out a way to see what libpath gs is using http://stackoverflow.com/a/11452233 but since I'm on Ubuntu that command (dump -Hv) won't work for me | 10:09.52 |
| | is there another way you guys know of for me to find out what the LIBPATH of my gs could be? | 10:10.07 |
| tkamppeter | chrisl, kens, I have added a comment to the Cairo bug https://bugs.freedesktop.org/show_bug.cgi?id=48260. | 10:10.54 |
| kens | nilli gs --help | 10:11.19 |
| | the search path is sent to stdout | 10:11.32 |
| nilli | oh, didn't see it there before.. thanks | 10:12.02 |
| kens | tkamppeter that seems to be reasonable | 10:12.26 |
| chrisl | nilli: or "env | grep LIBPATH" | 10:12.26 |
| kens | doens't grok enough Unix for the env command :-) | 10:12.44 |
| nilli | my env doesn't seem to have a libpath | 10:12.47 |
| kens | nilli probably why it doesn't work then | 10:12.59 |
| nilli | I just needed to know what path to set it to, gonna try that now | 10:13.15 |
| kens | You can use -I to include a path in the search order | 10:13.15 |
| chrisl | By default, I don't think LIBPATH is set. If it's not set, we'll use the "built-in" default | 10:13.46 |
| nilli | oh, so I can use gs -I to include the same library paths as from gs --help ? | 10:14.19 |
| kens | nilli yes, I believe so, I think ';' is the path spearator | 10:14.37 |
| nilli | will try | 10:14.49 |
| kens | THat is, the spearator between multiple paths | 10:14.50 |
| chrisl | tkamppeter: I did discuss that problem with a cairo developer a while back, and he said fixing the "pointless transparency" issues would be a *major* revamp | 10:15.00 |
| | nilli: the paths from gs --help are already searched by gs, so there's no need to add them with "-I" | 10:15.35 |
| kens | thinks chrisl can talk about paths, I don't think I'm explaining this well today | 10:16.16 |
| tkamppeter | chrisl, or would be the easier way to tell GNOME folks to drop Cairo (and what would be the replacement then)? | 10:16.26 |
| kens | I'm not sure there *is* a replacement for Cairo is there ? | 10:16.43 |
| chrisl | tkamppeter: I'm not aware of a single package that handles everything that cairo does | 10:17.06 |
| nilli | yeah, adding the --help paths with -I didn't change anything, not after I added /urs/lib either.. | 10:17.56 |
| kens | Hmm, I wonder if we could detect the Producer and then treat transparency sceptically (eg check softmasks for complete opacity etc). Or even preprocess looking for suprious transparency | 10:18.02 |
| chrisl | kens: seems like a horrid hack to me! | 10:18.22 |
| kens | chrisl yes, but then I don't think Cairo is going to go away. and by the sounds of things isn't likely to fix their transparency stuff either. | 10:18.48 |
| chrisl | kens: I suppose that's true - but preprocessing an entire softmask image.... yeuch! | 10:19.20 |
| kens | nilli I don't think the error is down to paths. What device are you using owth Ghostscript ? | 10:19.22 |
| | chrisl, yes, but you only need to look for 'not 0xFF' | 10:19.38 |
| chrisl | nilli: did you get the strace output? | 10:19.43 |
| nilli | I'll pastebin the script and its output | 10:19.45 |
| | no, not tried strace yet | 10:19.51 |
| chrisl | nilli: well, as the most common source of your error message is failing to open a file, it would be helpful to know if that's really the case, and if so, which file it is | 10:20.58 |
| nilli | if I sudo to the web user (www-data) which is the user the php script is running from, I have no issues running the gs command in the terminal, so that user has all necessary permissions in the target directory (which is set to 777 anyway) | 10:22.06 |
| chrisl | Well, if you won't try what we suggest to diagnose the problem, what do you expect us to do? | 10:22.56 |
| nilli | nothing more than answering my questions when I have some, which you did with the lib question | 10:23.43 |
| | not expecting you do to anything now :) | 10:24.02 |
| chrisl | Okay | 10:24.04 |
| | FWIW, strace -e trace=file gs -sDEVICE=pdfwrite -o stuff.pdf -c "showpage" will list file related system calls only, reducing the "noise" | 10:25.02 |
| kens | Hmm, our documentation on page orientation is wrong, it says we ignore the DSC comments, and we don't | 10:28.36 |
| chrisl | Maybe we used to ignore them? | 10:28.54 |
| kens | I don't think so, I don't thinkI added the code | 10:29.08 |
| | But its what is causing the customer problem | 10:29.18 |
| chrisl | Hmm, disable DSC parsing? | 10:30.07 |
| kens | I can't find out how to do that, trying to read our docs :-( | 10:30.24 |
| chrisl | Hmm, maybe you can't - that would be *bad*! | 10:31.13 |
| kens | I think normally you have to add PS code to handle DSC comments | 10:31.29 |
| | Ah looks like ProcessDSC, which doesn't appear to be documented..... | 10:31.56 |
| | ProcessDSCComments* | 10:32.12 |
| | Nope, not present in our docs, presumably because it is standard PostScript | 10:32.39 |
| kens | goes to check | 10:32.45 |
| nilli | my issue keeps getting weirder.. when running strace and my full gs command as you suggested, it works fine in terminal for the www-data user.. but when run through php I only get output from gs and an exit code 127 which seems to say command not found | 10:43.09 |
| | I'm gonna go find someone who knows stuff about executing bash scripts through php | 10:43.25 |
| chrisl | nilli: as an experiment, you could replace the -sDEVICE=pdfwrite with -sDEVICE=nullpage and see if Ghostscript runs to completion successfully (it will produce no output, and open no temporary files) | 10:54.47 |
| nilli | terminal execution of that results in a lot of 'No such file or directory', php execution gives exit code 127 | 10:59.36 |
| | strace -e trace=file /usr/bin/gs -o stuff.pdf -sDEVICE=nullpage | 10:59.46 |
| chrisl | Hmm, well, as I said yesterday, you're using a rather ancient Ghostscript release, so things may be different these days.... | 11:01.07 |
| nilli | yup.. | 11:01.49 |
| chrisl | What happens without the strace call, and without the absolute path to gs? | 11:02.21 |
| nilli | I get the copyright notice and no warranty | 11:02.41 |
| | 3 lines of text then back to my prompt | 11:02.49 |
| chrisl | Good, GS has run successfully. | 11:03.26 |
| nilli | unless I run it through php in which I get the 4th line with the initial device error | 11:03.30 |
| | gs -o stuff.pdf -sDEVICE=nullpage | 11:03.44 |
| | oh | 11:04.10 |
| | oooh | 11:04.12 |
| | if I remove all the fancy whitespace it works better ._. | 11:04.22 |
| chrisl | Which suggests something odd is happening to the command line...... | 11:04.23 |
| | "fancy" whitespace? | 11:04.37 |
| nilli | http://pastebin.com/ZUWu9QJy | 11:05.12 |
| | enters and spaces | 11:05.20 |
| | idiot doesn't quite describe what I feel like right now, I'm so sorry | 11:05.52 |
| chrisl | :-) | 11:06.02 |
| nilli | the original script works fine if I remove the extra whitespace | 11:06.25 |
| chrisl | If you want to split the command line over several lines, the "normal" method is to add a "\" before the carriage return | 11:06.41 |
| nilli | I didn't know that | 11:06.53 |
| chrisl | nilli: something like: http://pastebin.com/AzetVqix | 11:07.30 |
| nilli | yeah, that seems to work too, thanks | 11:08.11 |
| chrisl | nilli: I had assumed that was pastebin doing the line wrapping, rather than you.... | 11:08.23 |
| nilli | again, I'm really sorry | 11:08.49 |
| chrisl | Ah, these things happen.... | 11:09.09 |
| | bbiab | 11:10.03 |
| Robin_Watts | tor8: ping | 11:32.05 |
| | tor8: I think the scissor rectangle in fz_draw_fill_text is wrong for anything other than the first glyph | 12:05.29 |
| tor8 | Robin_Watts: I'm trying to figure out what I was thinking... it's not easy. | 12:10.19 |
| Robin_Watts | tor8: The main problem is that the scissor rectangle has x and y repeatedly subtracted from it during the loop. | 12:10.42 |
| tor8 | yeah. the subtraction is to compensate for the glyph origin. | 12:11.03 |
| | the scissor = state->scissor should probably move inside the loop | 12:11.15 |
| Robin_Watts | yeah, that's what I have here as a fix. | 12:11.26 |
| | I'm going to add a "glyph_scissored" function, that will fz_bound_glyph and compare to the scissor rect. | 12:12.05 |
| | then I can call that before every call to fz_render_glyph. | 12:12.16 |
| mupdf-lover | Hey Guys. Anyone there to explain me, why (latest git pull) mudraw wont render some text from my pdf(all fonts embedded)?! | 12:32.43 |
| Robin_Watts | mupdf-lover: No idea. Can you share the file please? | 12:33.08 |
| mupdf-lover | Sure! | 12:33.47 |
| | http://msvc.de/temp/mu-missing-text.zip | 12:33.48 |
| | The strings with the AmericanTypewriter font seem to be the problem. | 12:34.36 |
| Robin_Watts | mupdf-lover: I have my copy of mupdf in bits at the moment, so you'll have to give me a while to reassemble it. Can you hang around for a bit? | 12:35.46 |
| mupdf-lover | Sure, sounds fine! | 12:36.13 |
| | Dunno if it helps: Some very old gpl ghostscript (8.62) here renders the text correctly. | 12:41.25 |
| Robin_Watts | mupdf-lover: OK, back together and running a test now. let me look at your file. | 12:50.08 |
| mupdf-lover | I am curious :-) | 12:51.30 |
| Robin_Watts | OK, I see boxes instead of the chars. Is that what you see ? | 12:51.47 |
| mupdf-lover | Yep | 12:51.58 |
| kens | TrueType notdef glyphs ? | 12:52.44 |
| mupdf-lover | The only thing i can say, that _might_ help: Some old gpl ghostscript (8.62) here renders the text correctly. | 12:54.09 |
| kens | Sounds like and Encoding/CMap problem | 12:54.49 |
| mupdf-lover | I believe it, if you tell me ;-) | 12:56.01 |
| kens | CanI ask which text is missing ? | 12:56.56 |
| Robin_Watts | kens: The top 3 lines. | 12:58.40 |
| kens | "Name des Kindergartens" ? | 12:59.16 |
| Robin_Watts | yes. | 12:59.52 |
| kens | ok thx | 13:00.00 |
| mupdf-lover | Just uploaded the gs-version, containing the text: | 13:00.19 |
| | http://msvc.de/temp/mu-missing-text-by-gs.zip | 13:00.20 |
| kens | Current GS can render it just fine | 13:01.45 |
| | Its a straight TT font so there shouldn't be a problem. | 13:01.55 |
| tor8 | Robin_Watts: sounds good. | 13:02.09 |
| kens | (AmericnaTypewriter-Bold) | 13:02.12 |
| Robin_Watts | mupdf-lover, kens, tor8: http://ghostscript.com/~robin/missing3.pdf <- cut down file. | 13:03.36 |
| kens | Yeah you can delete the image for starters ;-) | 13:03.49 |
| Robin_Watts | tor8: If this is indeed a font encoding thing, it's going to be new ground for me - may be faster if you want to look at it? | 13:04.12 |
| kens | Its using WinAnsiEncoding, so I can't see an immediate reason for a difficulty | 13:04.33 |
| tor8 | the text makes it out as "unicode" from mudraw -t at least | 13:04.39 |
| | I'll poke around some more | 13:04.44 |
| | all gid=9 from mudraw -x though | 13:05.15 |
| | s/9/0/ | 13:05.19 |
| mupdf-lover | I dont know what you guys are talking about, but it sounds like you have some clues :-) | 13:05.50 |
| tor8 | kens: if you extract stream 11, an embedded truetype font, do you see something wrong with it? | 13:08.47 |
| kens | need a minute tor8 | 13:08.59 |
| tor8 | it looks truncated at glyf entry 94 going by my ttfdump tool | 13:09.13 |
| kens | object 11 is a color space fror me | 13:09.44 |
| tor8 | robin's cut down missing3.pdf | 13:09.54 |
| kens | I didn't save it, because my PDF viewer said there was something wrong with ti, one moment | 13:10.17 |
| Robin_Watts | Really? missing3.pdf is the output from pdfclean, so if there is a problem, I'd like to know. | 13:11.41 |
| kens | Hmm its Flate encoded I'll have to decompress it | 13:11.45 |
| tor8 | if I take out the FontFile2 entries, the text shows up | 13:12.06 |
| kens | Robin_Watts : Acrobat is happy with it | 13:12.06 |
| tor8 | so I think there may be something freetype doesn't like with it | 13:12.15 |
| kens | tor8 but then you'll be substituting, right ? | 13:12.19 |
| | tor8 GS uses FreeType too | 13:12.27 |
| | Thgouh differently I grant you | 13:12.37 |
| tor8 | kens: yes. then I'll substitute. so there's nothing wrong with the /Encoding stuff in the file. | 13:12.40 |
| Robin_Watts | kens: Which pdfviewer said there was a problem with it? | 13:13.02 |
| tor8 | kens: quite probably. I suspect it's cmap-related. | 13:13.07 |
| kens | Robin_Watts : Don't know | 13:13.18 |
| tor8 | since it uses the font but it comes out with all gid=0 | 13:13.21 |
| kens | Give me a minute, nearly there | 13:14.03 |
| | There's osmething not good with the font | 13:15.02 |
| | tor8 the glyphs are not truncated. they have a length of 0 that's OK | 13:17.57 |
| | It has some funny names | 13:18.35 |
| | It has a format 4 CMAP could that be the trouble ? | 13:19.15 |
| | Its a 2-byte CMAP | 13:20.02 |
| | THere's a format 6 CMAP too | 13:20.44 |
| tor8 | oh this is lovely. my Xcode seems to have upgraded itself and now it's lost the X11 libraries... | 13:20.50 |
| kens | tor8 the format 6 CMAP is nonsense, are you by chance using that ? | 13:21.07 |
| | the format 6 table maps all glyphs to 0 | 13:21.18 |
| tor8 | kens: I might. something's making all the glyphs map to zero when extracting the "default" truetype encoding. | 13:21.36 |
| | I just need to swear and cuss some more at apple for breaking my environment yet again with something completely unrelated. | 13:22.02 |
| kens | There are 2 CMAP subtables, the format 4 one looks OK, the format 6 one looks like its wrong. | 13:22.09 |
| tor8 | kens: yeah, the format 6 one is definitely broken | 13:24.21 |
| kens | Yes that's what I see, no idea how you use that in MuPDF though | 13:24.51 |
| Robin_Watts | tor8: Can we spot that it's broken and drop back to the format 4 one? (Possibly a stupid question, I have no clue about this stuff) | 13:24.59 |
| | (maybe freetype should do that?) | 13:25.11 |
| kens | IMO the format 4 one is the primary | 13:25.13 |
| | Also, the font shopuld not contain a broken CMAP, that's just bad | 13:25.31 |
| Robin_Watts | What's the difference between format 4 and format 6? | 13:25.34 |
| | 8 vs 16bit or something? | 13:25.44 |
| tor8 | Robin_Watts: format 6 is a simple 256-entry lookup table | 13:25.54 |
| kens | Err no its more complicated than that | 13:25.55 |
| tor8 | kens: we look at the platform/encoding pair to pick a cmap | 13:26.45 |
| Robin_Watts | "Format 4 is used for 16 bit mappings. Format 6 is used for dense 16 bit mappings." according to Mr Google | 13:26.47 |
| kens | but the content of the two tables should be equivalent, and it isn't | 13:26.52 |
| tor8 | 3,0 has preference only if the symbolic flag is set, otherwise it takes 3,1 then 1,0 | 13:27.08 |
| kens | Robin_Watts : Yes, but that's not entirely true. Its a useful approximation | 13:27.30 |
| tor8 | Robin_Watts: in general format 6 is used for apple compatibility to have the MacRoman encoding (1,0) | 13:27.38 |
| | and format 4 or more advanced cmap formats for microsoft and unicode cmaps | 13:27.55 |
| kens | You can't do 16-bit mappings in format 6, but you can use it even so | 13:28.12 |
| | this font has neither a 3,1 nor a 3,0 table | 13:29.46 |
| | but the 1,0 is clearly wrong | 13:29.58 |
| | the format 4 table is 0,2 | 13:30.21 |
| | Duh, sorry it *is* 3,0 | 13:30.35 |
| | d'oh again, actually its 0.3 | 13:30.58 |
| | Platform ID 0, specific id 3 | 13:31.15 |
| | Looks like whoever did this screwed up the IDs, platform ID 0 seems to be undefined | 13:33.22 |
| | I think it is supposed to be 3,0 but they wrote the data the wrong way round | 13:33.41 |
| tor8 | Robin_Watts: d'oh! I should be more vigilant in reviewing some commits. | 13:34.28 |
| kens | Robin_Watts: ` the PDF viewer I was using was pdf.js | 13:34.34 |
| tor8 | 61c1f80d36bf1d946ce26d39f9afb99897fc9923 broke macosx builds | 13:34.35 |
| | kens: yeah. that 0,3 looks odd. | 13:35.03 |
| kens | Ah, according to this a platform ID of 0 is Apple UInicode | 13:35.30 |
| tor8 | kens: which should never be used by the pdf spec unless it's the only cmap in the file, if I've read the spec correctly | 13:36.01 |
| kens | tor8 yes I htink that's correct. | 13:36.16 |
| | You could ask chrisl how GS is managing this | 13:37.14 |
| | But I suspect we are doign teh CMAP management ourselves | 13:37.25 |
| tor8 | I think we can agree that it's a broken file. the question is how gs and other viewers can cope with it. | 13:39.25 |
| kens | tor8 0,3 is definitely wrong for a Latin file. 0,3 is Apple Unicode 'Korean' | 13:40.15 |
| | D'uh, no it isn't (I hate this spec) | 13:40.34 |
| | 3 means 'Unicode 2.0 or later' | 13:40.44 |
| tor8 | mupdf is selecting cmap 1,0 for both embedded fonts | 13:41.00 |
| kens | As I believe it should | 13:41.09 |
| tor8 | is there an easy way to see which cmap gs selects? | 13:41.11 |
| kens | Err, no. | 13:41.16 |
| | ping chrisl and ask him :) | 13:41.25 |
| tor8 | chrisl: ping! :) | 13:41.33 |
| chrisl | tor8: pong | 14:15.34 |
| | Oh, you want a way to see which cmap table GS is using? Try -dTTFDEBUG - I think it's listed somewhere in the output from that | 14:17.17 |
| | (sorry, my parents are here.....) | 14:17.26 |
| Robin_Watts | Hi malc_. Just testing a change now. | 14:19.58 |
| malc_ | Robin_Watts: can i lend a hand? | 14:20.22 |
| Robin_Watts | As soon as I have a patch I'm happy with, that would be much appreciated. | 14:20.38 |
| kens | GS claims to be using cmap 1.0 for non-symbolic | 14:21.50 |
| | and says the format is format 6 | 14:22.20 |
| | The entries it comes out with do not macth ttfdump | 14:22.38 |
| | Suggests ttfdump has a bug | 14:23.51 |
| Robin_Watts | http://deals.macupdate.com/ | 14:25.54 |
| | For mac users who don't have parallels already, this is a bargain. | 14:26.05 |
| henrys | I seem to do okay with virtual box | 14:28.50 |
| | but I don't use it often | 14:29.09 |
| | my read of tkamppeter's message is we need to add color management and postscript out to mupdf, just sayin' | 14:30.34 |
| kens | We could do PS output by taking opdfread on the fornt of MuPDF output :-) | 14:33.36 |
| | But I do not reccomend that approach | 14:33.46 |
| | (in case the smiley wasn't enough) | 14:33.59 |
| Robin_Watts | opdfread being? | 14:34.07 |
| kens | the PostScript prolog that pdfwrite uses | 14:34.17 |
| tkamppeter | henrys, also a good idea for a mobile, low-footprint renderer. How much is missing for that goal? And how much memory does mupdf take up compared to GS and Poppler? | 14:34.22 |
| kens | pdfwrite emits a PDF file with some omissions and a big Procset to redefine the PDF operators | 14:34.38 |
| Robin_Watts | MuPDF could easily output a PS file full of images... | 14:34.57 |
| kens | tkamppeter : MuPDF is already a lightweight renderer, its used on iOS and android already | 14:35.00 |
| | Robin_Watts : ick | 14:35.06 |
| Robin_Watts | kens: indeed. but how else can we do transparency ? | 14:35.28 |
| kens | Robin_Watts : you can't but many PDF files don't use transparecny (modulo Cairo) | 14:35.43 |
| henrys | tkamppeter: you should really have a look we completely dominate the android ecosystem, free pdf wise we think we have a lot to offer in the mobile space. | 14:35.51 |
| kens | and I betMuPDF could tell more easily than GS if a given PDF actually *used* transparency | 14:36.08 |
| Robin_Watts | kens: We traverse the structure already, looking for that. | 14:36.29 |
| tkamppeter | henrys, is the default PDF viewer of Android mupdf (or GS) based? | 14:36.36 |
| Robin_Watts | tkamppeter: there is no default PDF viewer for android. | 14:37.00 |
| kens | Robin_Watts : yes but I was thinking of eliminting spurios transparency, eg opaques softmasks | 14:37.03 |
| Robin_Watts | Most devices come with a PDF reader included, but there is no standard one. | 14:37.22 |
| tkamppeter | Robin_Watts, so a fresh Android device is not capable of displaying PDF? | 14:37.39 |
| Robin_Watts | Lots of people bundle "office suites" that can do PDF import/display. | 14:38.01 |
| | And Adobe have a mobile PDF reader. | 14:38.12 |
| | If you look at the free apps out there on google play that do PDF reading, almost all of them are MuPDF based. | 14:38.32 |
| saper | tkamppeter: various providers of handsets install different stuff, some go even with Adobe. If you install CyanogenMod, there is none; I installed mupdf but didn't figure out how to zoom so I can actually read a page | 14:38.42 |
| Robin_Watts | saper: pinch zoom. | 14:39.02 |
| tkamppeter | Robin_Watts, so the PDF viewer is usually added by the hardware manufacturer (Samsung, LG, ...)? | 14:39.07 |
| kens | There's PDF.js for the browser | 14:39.10 |
| Robin_Watts | tkamppeter: Indeed. | 14:39.14 |
| | kens: Not for general browsers, AIUI. I think that relies on mozilla specifics, but I could be wrong. | 14:39.41 |
| tkamppeter | So Nexus devices will probably come without? | 14:39.45 |
| kens | has no idea | 14:39.48 |
| Robin_Watts | And really, that'd be dog slow on a mobile device. | 14:39.49 |
| | tkamppeter: No. Nexus devices have a bundled one. | 14:40.04 |
| | based on Repligo, I believe. | 14:40.19 |
| | but MuPDF is faster, and crashes way less than that. (Not our words, words from someone 'independent' who has tested both) | 14:41.09 |
| henrys | I wonder how much work it would be to port reflow and annotations to ubuntu - probably quite a bit - for our android build has the nice mobile features. | 14:41.12 |
| saper | Robin_Watts: no multi-touch (yet) | 14:41.16 |
| tkamppeter | I have searched for mupdf on Google Play and after the original MuPDF come several others using the MuPDF library. | 14:41.28 |
| Robin_Watts | saper: Well, without multitouch, you're screwed with the standard app. What device is this on? | 14:41.45 |
| saper | Huawei "Ideos" U8150, very popular in Kenya | 14:42.14 |
| Robin_Watts | saper: Hmm. I guess we'd need to add on screen zoom in/out icons when multitouch is not available. | 14:42.58 |
| | Probably not a huge job. | 14:43.14 |
| | paulgardiner: Any thoughts ? | 14:43.18 |
| henrys | tkamppeter: so I guess X11 is history on these mobile devices - what are you using? | 14:43.22 |
| paulgardiner | Just reading back | 14:43.50 |
| saper | Robin_Watts: would be nice, I am a big fan of mupdf on my desktop | 14:43.56 |
| paulgardiner | Oh yeah. Not rocket science I'd have thought. | 14:44.37 |
| | Double-tap-drag is maybe another possibility | 14:45.35 |
| saper | oh, even better | 14:46.08 |
| | the device has arrow-like middle button so it could be used as well (probably not a standard android feature) | 14:46.40 |
| Robin_Watts | paulgardiner: double-tap drag sounds good to me, but only in the non-multitouch case, ideally. | 14:47.55 |
| | http://stackoverflow.com/questions/11021280/detect-multi-touch-capabilities-android | 14:48.38 |
| paulgardiner | Yes, or a dragable thing like the page selector | 14:48.58 |
| henrys | kens, chrisl so is it best to have a project maybe ps3write where we aim to get rid of problematic areas or should be just fix things as they come in? | 14:50.16 |
| | s/be/we | 14:50.31 |
| saper | need to check what the stackoverflow says; there are rumors that the screen is really multitouch but there is a problem with spec/driver for CyanogenMod (stock ROM is single touch too) | 14:50.43 |
| | so it certainly should say "not multitouch" on the pkgmgr level | 14:51.15 |
| Robin_Watts | saper: The purpose for supporting this would be to ensure that we cover as many devices as possible, not just for one specific device. | 14:51.27 |
| kens | henrys two different problems | 14:51.50 |
| | firstly buggy postscript pritners, secondly ps3write would let us do stuff we currently can't (Flate encode, CIDFonts, shadings) | 14:52.22 |
| henrys | well there are several problems all under printing successfully | 14:52.45 |
| kens | I can 'improve' ps2write as is up to a point by revamping the code somewhat, but rtehre's no way I can accoutn for all the vagaries of PS bugs. | 14:52.57 |
| saper | Robin_Watts: definitetly that should be the goal | 14:53.00 |
| kens | henrys, and if you look at teh bug reports I poitned Till at this morning, its clear Poppler had very simmilar problems | 14:53.20 |
| henrys | printer compatibility project we'd call it , and ps3write would be one aspect of it. | 14:53.32 |
| kens | I'd prefer to treat them separately | 14:53.49 |
| | In essence we are already doign the 'compatibility' project | 14:54.05 |
| tkamppeter | I have downloaded and tried out MuPDF on the Nexus 7 (Android 4.2) now and it renders CityMap.pdf and launch_leaflet.pdf perfectly, even the version of CityMap which comes out of Evince. It needs some seconds to get images to the native screen resolution though, but having a low-res preview in place up to then it is no big deal. I can imaging that the Nexus 7 will print these files with MuPDF in a reasonable time. | 14:54.18 |
| Robin_Watts | AIUI, we've (chrisl/kens really) already solved all the problems that have come in to us with dodgy printers, right? | 14:54.38 |
| kens | henrys cf your agenda item, 'policies and miscellaneous' #6 | 14:54.46 |
| mupdf-lover | Robin_Watts, mupdf-lover, kens, tor8: http://ghostscript.com/~robin/missing3.pdf is defect and wont work for mupdf or is there hope? | 14:56.15 |
| Robin_Watts | mupdf-lover: One of the embedded fonts is broken. | 14:56.37 |
| kens | Robin_Watts : I'm not certain of that, it works ok in GS | 14:56.57 |
| | but I don;'t know why yet | 14:57.03 |
| Robin_Watts | We're waiting for (one of our) font experts to look at it to compare with how gs works. | 14:57.04 |
| henrys | kens:yes that was my question do we continues in the vane or do we carefully compare poppler output with ours and see what works and doesn't work on odd printers. | 14:57.42 |
| mupdf-lover | Ah, OK.... Thanks! | 14:57.54 |
| henrys | s/in the/in that/ | 14:57.55 |
| kens | henrys we don't know what Poppler have done to account for broken printers. | 14:59.13 |
| chrisl | henrys: there are too many differences in the implementation details for that approach to work, IMO | 14:59.14 |
| | kens: are you looking at the font problem, or do you want me to? | 14:59.30 |
| kens | chrisl I'm not | 14:59.39 |
| Robin_Watts | henrys: and they haven't said "keep the number of bind operations below 123" etc. | 14:59.40 |
| chrisl | Stupid firefox, I don't want the PDF opened! | 15:00.15 |
| kens | Robin_Watts : I suspect they haven't tripped over that one (yet). THat's one of the ones I cna probably address | 15:00.36 |
| | I can probably also do something about the filter chains. But a broken CCITT G4 fax decoder is inexcusable | 15:01.21 |
| henrys | tkamppeter: FWIW we probably have 2 full time staff members doing something in the mobile space at any given time these days. | 15:01.42 |
| tkamppeter | Robin_Watts, on-screen zoom buttons in MuPDF are important, as Android is not only available on phones and tablets but also on HDMI-stick mini PCs/set-top boxes for TVs. | 15:01.53 |
| henrys | chrisl, and others: fair enough. | 15:02.13 |
| chrisl | Robin_Watts: we still have a couple of outstanding crappy printer bugs | 15:02.35 |
| henrys | should we have a fallback to something like pswrite? | 15:03.29 |
| kens | How would we know when to use it ? | 15:03.41 |
| | we already have fallback code to use if we are told to | 15:03.51 |
| henrys | the user would decide | 15:03.52 |
| kens | See above | 15:03.57 |
| henrys | oh okay | 15:04.04 |
| kens | Till uses it against certain printers | 15:04.07 |
| chrisl | henrys: "ps3write" would fix a couple of gripes (not failures to print, but performance related) *and* would give us more ways to work around certain printer bugs. | 15:04.30 |
| kens | Oh, and pswrite uses CCITT G4 fax quite extensively, at least one of these pritner bugs will exhibit with pswrite otuput | 15:04.33 |
| Robin_Watts | chrisl: So these buggy printers that don't support PS level 2 properly support ps level 3 at all ? | 15:05.37 |
| kens | as badly one suspects | 15:05.50 |
| henrys | kens:but presumably CCITT G4 could be set to something else in the PPD, right? | 15:06.24 |
| chrisl | Robin_Watts: some of them are level 3, yes. So, for example, one of the bugs was ASCII85 encoded, LZW compressed image data was falling over: but ASCIIHex, LZW was fine. ASCII85, Flate, was fine. ASCIIHex, Flate was fine....... | 15:07.27 |
| Robin_Watts | tor8: A problem... If you look at tests_private/comparefiles/Bug689753.pdf page 1, you'll see that we obviously don't have the bullet point glyph in a font. | 15:09.41 |
| | so it's being rendered as a box. | 15:09.47 |
| | The recorded glyph bbox for that is an empty box. | 15:09.56 |
| | Ah, I see why. The gid is 65448 which is too big to be recorded in the bbox_table. | 15:12.24 |
| | so it uses font->bbox, which is empty for non t3 glyphs. | 15:12.50 |
| | Can we not make it infinite for non t3 glyphs ? | 15:12.58 |
| | or (better) can we not get a bound from freetype? | 15:13.16 |
| chrisl | Hmmmm, in missing3.pdf both Ghostscript and mupdf seem to be using the 1,0 cmap........ | 15:15.27 |
| tor8 | Robin_Watts: we use the glyph bboxes to calculate text bboxes | 15:17.53 |
| Robin_Watts | Right. It seems that in fz_new_font_from_memory freetype is returning face->bbox as being all zeros. | 15:18.20 |
| tor8 | fz_bound_glyph could have a better (slower) fallback case though | 15:18.38 |
| Robin_Watts | Is freetype allowed to do that ? | 15:19.05 |
| tor8 | fz_new_font initialises font->bbox to [0 0 1 1] | 15:19.28 |
| Robin_Watts | and fz_new_font_from_memory then writes the true value in. | 15:19.48 |
| tor8 | fz_set_font_bbox sets it to its proper values from freetype or the type3 bbox entry | 15:19.52 |
| Robin_Watts | based on face->bbox | 15:19.58 |
| chrisl | Is freetype allowed to do what? | 15:19.59 |
| Robin_Watts | and face->bbox is all zeros. | 15:20.04 |
| | chrisl: Is freetype allowed to return us a face rfom FT_New_Memory_Face with the bbox set to 0's ? | 15:20.32 |
| chrisl | If that's the setting in the font, then what else can it do? | 15:20.51 |
| Robin_Watts | Supposedly there are 123 glyphs in this font. | 15:21.01 |
| chrisl | FontBBox is part of the font data, it is not a "derived" value | 15:21.33 |
| Robin_Watts | chrisl: So, is that commonly broken in fonts ? | 15:21.45 |
| tor8 | Robin_Watts: I don't think many bits of software rely on correct bboxes being set these days | 15:22.07 |
| chrisl | I wouldn't say it's common, but not unheard of | 15:22.11 |
| Robin_Watts | ok, so it's something we should cope with then. | 15:22.38 |
| | That's a pain. | 15:22.40 |
| tor8 | so they're probably going to be wrong more often than not in newer fonts | 15:22.41 |
| | Robin_Watts: agreed! | 15:22.46 |
| Robin_Watts | tor8: What 'better fallback case' could we have in fz_bound_glyph ? | 15:23.00 |
| tor8 | it'd be a simple test to say if bbox is empty, make it infinite in the new_font_ stuff | 15:23.04 |
| | we could do the same as when we fill in the bbox_table, but simply not cache the data | 15:23.40 |
| | that'll be awfully slow where the performance already hurts us -- chinese fonts | 15:23.59 |
| chrisl | Robin_Watts: why do you need the font bbox? | 15:24.54 |
| Robin_Watts | chrisl: To avoid having to make an expensive call to freetype to tell it to tell me the bbox for a real glyph. | 15:25.20 |
| | tor8: Could we spot the bbox being empty in fz_new_font and run through the glyphs bounding them all and forming the union? | 15:26.15 |
| chrisl | Well, why not have the fallback be the call to freetype for the actual glyph bbox? | 15:26.22 |
| Robin_Watts | chrisl: That's what tor8 just suggested. | 15:26.37 |
| tor8 | Robin_Watts: we could. or we could just detect it as being broken and pick a reasonable default (but that won't be bulletproof) | 15:26.41 |
| | or do the slow fallback if we detect it as being broken | 15:26.54 |
| | and use the font bbox if it looks reasonable | 15:27.02 |
| Robin_Watts | how slow is freetype at asking for a bbox? | 15:27.12 |
| | Presumably it can find out from the glyph without walking the outlines ? | 15:27.26 |
| tor8 | Robin_Watts: it needs to load the glyph, so it has to interpret the charstring or outline and then find the bounds | 15:27.39 |
| Robin_Watts | tor8: so it does walk the outlines. Damn. | 15:27.59 |
| chrisl | Robin_Watts: you want to use the CBOX rather than the BBOX from freetype | 15:28.00 |
| tor8 | and if the font has triggered the DynaLab workaround, it also has to run the bytecode hinter on it | 15:28.00 |
| Robin_Watts | chrisl: The CBox being a rougher one? | 15:28.20 |
| | i.e the bbox that contains all the control points, rather than the bbox that contains all the rendered lines ? | 15:28.37 |
| chrisl | Yes. If you ask for the BBox it will scan convert the outline to find a "proper" BBox | 15:28.55 |
| Robin_Watts | That's still going to require the outlines to be walked though, right? | 15:29.09 |
| | just not scan converted. | 15:29.18 |
| tor8 | Robin_Watts: yeah. unpacked, grid fitted, and walked. | 15:29.48 |
| | which is why we have the bbox_table cache | 15:30.03 |
| chrisl | tor8: doesn't freetype keep a "rolling record" of the bounding box as it constructs the path? | 15:30.51 |
| Robin_Watts | Are ascent and descent stored per glyph? Or are they calculated values? | 15:31.12 |
| tor8 | chrisl: not sure about the details, actually | 15:31.21 |
| | Robin_Watts: no font format I know of has stored ascent/descent per glyph | 15:31.42 |
| chrisl | Robin_Watts: FWIW, rattling through all the glyphs and unioning the bounding boxes would *really* hurt performance, especially in kanji fonts...... | 15:32.56 |
| Robin_Watts | I suspect that we should spot the font bbox being null, and put in either an infinite bbox, or a large one. | 15:34.44 |
| | An infinite bbox should be safe. | 15:34.51 |
| | a large one will be safe, unless fonts are stupidly big. | 15:35.13 |
| tor8 | Robin_Watts: that'd not work for calculating the area of a page that has marks on it though | 15:35.22 |
| | since then all text using that font would be infinite in size | 15:35.37 |
| Robin_Watts | tor8: true. | 15:35.41 |
| | Anything other that the 'exact' figure would be wrong though. | 15:35.56 |
| | At the moment, we use a zero size box, so the area of the page thusly calculated would be too small. | 15:36.23 |
| tor8 | Robin_Watts: yes, but it'd be an area at least :) | 15:37.16 |
| chrisl | Robin_Watts: for western fonts, I've used +/- 2 * the extents of the "M" glyph, but something similar for far eastern fonts would be even more dodgy..... | 15:38.01 |
| tor8 | [-1 -1 2 2] should be big enough to cover all non-funky fonts | 15:38.02 |
| Robin_Watts | All '12-point' fonts are 'more or less' the same, right? | 15:38.20 |
| | tor8: right, that was what I was after. | 15:38.26 |
| tor8 | Robin_Watts: that won't work if they abuse the fontmatrix, but for any reasonable font that should be more than enough | 15:39.10 |
| | typical values are [-.5 -descender 1 ascender] | 15:39.41 |
| chrisl | tor8: are you looking into the missing3.pdf font problem? | 15:40.05 |
| tor8 | chrisl: I was, but then I got attacked with lots of questions :) | 15:41.03 |
| chrisl | tor8: :-) Okay, I'll leave it with you - if you want me to poke at it, let me know | 15:41.32 |
| tor8 | chrisl: and now I have to /afk for a bit. I will keep looking later unless someone else finds out what's wrong. | 15:41.33 |
| chrisl | tor8: I'll be heading out shortly, too | 15:41.55 |
| Robin_Watts | We could spot that the face->bbox is invalid, and use the [-1 -1 2 2] as a default, but also set a bbox_dodgy flag. | 15:46.02 |
| | And whenever we find the bbox for a glyph by doing a real measurement, union that with the stored bbox. | 15:46.32 |
| | hence the bbox would 'improve' over time. | 15:46.44 |
| | but then I don't think we ever use the stored bbox when we do any direct measurements, so that would be pointless. | 15:47.13 |
| | OK. What I've got here should do. | 15:47.19 |
| henrys | I'm impressed with how quickly Wikipedia updated gs to AFGPL | 15:49.59 |
| | AGPL | 15:50.18 |
| chrisl | henrys: that's good - I probably should have told someone about it! | 15:51.05 |
| Robin_Watts | malc_: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=6836ad84a9eaa8fb3bc26ed36284bbf8b9f38c40 | 15:57.50 |
| | malc_: See how that does for you. | 15:57.56 |
| tor8 | Robin_Watts: new_font_from_file will suffer the same bugs. we should use fz_set_font_bbox in both, and do the test there | 16:00.10 |
| Robin_Watts | tor8: Will update the code for that. | 16:00.25 |
| henrys | great big storm coming in the day I leave for Miami. | 16:04.03 |
| Robin_Watts | henrys: Are you bringing Sabrina ? | 16:04.45 |
| henrys | no just coming for the meeting | 16:05.07 |
| Robin_Watts | tor8, malc_: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=d9f836e471c8d774883d643f4966b7a42cafc0b1 | 16:06.08 |
| henrys | I don't know if this guy is considered a quack in the UK but I agree with this, I've been doing occasional fasts for a while now and I like some of the effects. http://www.nytimes.com/2013/03/03/fashion/england-develops-a-voracious-appetite-for-a-new-diet.html?_r=0 | 16:10.47 |
| Robin_Watts | It's a fad diet. Fad Diets Don't Work. Ever. | 16:12.09 |
| kens | Robin_Watts : they might work but they don't address the underlying eating problem, they don't change habots | 16:15.07 |
| Robin_Watts | kens: Every one of us carries around about half a stone of excess fluid. Fad Diets tend to help people lose that fluid quite quickly, and people think "Wow this works!" | 16:16.16 |
| | but no one ever sticks to a fad diet, so they never realise that it never loses them more than that half stone. | 16:16.45 |
| kens | Robin_Watts : both my sister and mother are capable of losing weight on any fad diet. Then they put it back again | 16:16.46 |
| henrys | I saw his BBC special - he does talk about some research pointing to fasting being superior to traditional calorie reduction. | 16:16.51 |
| Robin_Watts | mmm. research. That's what they refer to in the shampoo ads, right? :) | 16:17.17 |
| malc_ | Robin_Watts: can't say i see an improvement | 16:17.35 |
| Robin_Watts | Essentially, if you want to lose weight, you need to keep your calories in below your calories out for a sustained period of time. That's not nice, it's not enjoyable, it doesn't give you instant results, but it does give you long term results. | 16:18.21 |
| henrys | fasting works for rodents - little controversy about that - the primate studies are uncler. | 16:19.47 |
| | s/uncler/unclear | 16:19.54 |
| Robin_Watts | has lived on a diet for the past 5 years or so and has lost ~25% of his body weight since his peak. I wish fad diets worked... | 16:20.51 |
| kens | Robin_Watts : agreed. | 16:21.34 |
| | Just saying that its possible to lose wieght on them but.... | 16:21.51 |
| henrys | what he suggests is 5:2 - 2 days very low calories (600 male) why is that any more a fad than weight watchers? | 16:22.15 |
| malc_ | gained 10kg in a week last year and then lost them in a week afterwards | 16:23.16 |
| | wasn't fun | 16:23.18 |
| Robin_Watts | kens: I think that mostly it's just fluid loss, and also it forces people to actually look at portion sizes. Any real reductions are probably down to the fact that you start to make more concious decisions aobut what you actually eat. If people kept that up long term they might properly lose weight. | 16:23.53 |
| | henrys: Weight watchers is just a way of calorie counting. Calories in > calories out long term = weight loss. That's not a fad. | 16:24.43 |
| | Maybe i'm being unkind about this fasting diet thing. | 16:24.58 |
| | (oops <, not > ) | 16:25.19 |
| paulgardiner | I've been trying the 5:2 thing last 5 or so weeks. | 16:25.26 |
| | Trying to prepare for every day at Dennys for a week. | 16:25.49 |
| Robin_Watts | If the fasting thing breaks down to calories in < calories out, then great. | 16:25.50 |
| henrys | paulgardiner: did you see the bbc special | 16:26.12 |
| | ? | 16:26.14 |
| paulgardiner | With 5:2 you aren't supposed to eat any more than usual on the 5 days | 16:26.16 |
| | henrys: not sure. I saw a Horizon program about 3 - 6 months ago. | 16:26.46 |
| henrys | I think that's the same one. | 16:27.14 |
| paulgardiner | That wasn't really about 5:2, just fasting in general. | 16:27.16 |
| | henrys: yeah probably. | 16:27.26 |
| henrys | well the punchline at the end was these other programs (fasting) are too hard use 5:2 | 16:27.45 |
| paulgardiner | Very interesting, but I guess just because it reduces the indicators of disease in the blood it doesn't necessarily reduce the disease. | 16:28.04 |
| henrys | you are reducing calories the same as any traditional diet - the question is are there benefits to doing it this way. I would be more in line with how we evolved. | 16:28.51 |
| | s/I would/It would/ | 16:29.10 |
| paulgardiner | henrys: yeah, I'm sort of open minded about it. Really I'm just using it as a way to reduce calories without every day being miserable. | 16:29.38 |
| Robin_Watts | henrys: Honestly, this sounds a lot like the "Every Other Day Diet" that was hawking itself around the internet in website ads a while ago. | 16:30.01 |
| paulgardiner | Robin_Watts: yes that one was in the program too. | 16:30.25 |
| Robin_Watts | Call me cynical, but I find it hard to believe in anything that sells itself via the same mechanism as viagra and cialis :) | 16:31.11 |
| paulgardiner | It isn't a particularly new idea. They've know that they can increase the life span of rats by something like 1.5 by low cal diets for decades | 16:31.24 |
| | Robin_Watts: it's only just hit that medium. It's been around for ages | 16:31.45 |
| henrys | it's here, but I don't know if it is legal to watch it: http://vimeo.com/50912488 | 16:32.28 |
| | it was a bbc program that's why I was asking if you guys were up on it. | 16:33.10 |
| paulgardiner | Robin_Watts: definitely worth a watch just for interest. | 16:33.12 |
| kens | henrys I was a\ware of the diet, I'm with RObin opinion wiae though | 16:33.29 |
| Robin_Watts | henrys: I only watch american TV, pretty much :) | 16:34.08 |
| tor8 | Robin_Watts: I meant to reuse the already existing fz_set_font_bbox function :) | 16:34.27 |
| henrys | I do fast in the off season can't do it when I'm training | 16:34.39 |
| Robin_Watts | tor8: oh, I missed that entirely. I'll look. | 16:34.55 |
| paulgardiner | henrys: what sort of fasting? 5:2? | 16:35.07 |
| henrys | no I just do one day, it really is just a mental thing for me. And interestingly that program points out that fasting leads to neurogenesis in rats. | 16:36.11 |
| | about once a month. | 16:36.26 |
| | just water | 16:37.11 |
| paulgardiner | ah right. A whole day eating nothing. I haven't tried that. | 16:37.47 |
| Robin_Watts | I've tried a whole day eating. | 16:38.55 |
| paulgardiner | Come on we've done continuous fortnights. | 16:39.27 |
| henrys | ;-) | 16:39.27 |
| Robin_Watts | Bacon Countdown at 42 hours or so... | 16:39.59 |
| paulgardiner | Stop it! You have me doing a count down now. | 16:40.28 |
| henrys | It has the effect of more alertness and awareness for me - probably because my rat like brain has gotten the message, it's time to get serious about noticing stuff that might lead to food. | 16:45.16 |
| Robin_Watts | malc_: Lack of an improvement is annoying. | 16:47.28 |
| marcosw | henrys: I wanted to log in to your macpro to check on some cluster stuff but I can't connect. | 17:00.11 |
| henrys | marcosw: are you using an IP address or hostname? | 17:01.12 |
| marcosw | a hostname | 17:01.26 |
| henrys | I did change my router, that might have fouled things up. | 17:01.34 |
| | this is my IP | 17:02.16 |
| | 50.134.235.109 | 17:02.19 |
| marcosw | that's what the hostname I'm using resolves to. | 17:03.49 |
| henrys | okay so the router isn't forwarding properly | 17:04.07 |
| | so I need to check that port 22 is going to Mac Pro hang on. | 17:05.56 |
| | what exactly is meant by internal starting port vs. external. | 17:10.36 |
| | ? | 17:10.37 |
| Robin_Watts | henrys: You want your external port to be 22. | 17:11.47 |
| | You want your internal port to be 22. | 17:11.52 |
| | That means when I connect to the router on your external port, that forwards to the internal address on the internal port. | 17:12.16 |
| | So for security you could make your external point 2222, say. | 17:12.29 |
| | Then marcosw would need to connect to 50.134.235.109:2222 | 17:12.45 |
| henrys | okay I was worried it was going to do something with port 22 stuff going out from my local network. | 17:12.59 |
| Robin_Watts | The idea being that port 2222 is less likely to be hit in a portscan. | 17:13.11 |
| marcosw | Robin_Watts: port knocking is the answer | 17:13.32 |
| Robin_Watts | Of course it also means that you can forward port 22 to macpro, port 23 to henrysx6:22 etc. | 17:13.34 |
| henrys | yes we should probably do that. | 17:13.40 |
| Robin_Watts | marcosw: port knocking is an answer, certainly. | 17:14.13 |
| henrys | what's the hostname you are using marcosw? | 17:14.18 |
| marcosw | henry-artifex.homeip.net | 17:14.33 |
| | artifex has an account on dyn.com and I run an updater on macpro from my account | 17:15.08 |
| henrys | yes right but I think you had given us another name as well. | 17:15.35 |
| | works for me. | 17:16.36 |
| marcosw | macpro.ghostscript.com, but I think that just redirects to henry-artifex.homeip.net | 17:17.17 |
| henrys | you also need henrysx6 - it has a static IP or I can use Robin_Watts suggestion if you like | 17:17.45 |
| | local static IP reachable from macpro | 17:18.07 |
| | o | 17:18.15 |
| marcosw | I'm happy to log in to your macpro and then log into henrysx6 | 17:18.18 |
| | that's what I do at home and also how alexcher has his computers configured. | 17:18.31 |
| henrys | well I think symbolic names are broken which is why I suggested it. Using DHCP reservations not real DNS | 17:18.58 |
| marcosw | the more machines you have open to the outside the more likely someone can get in, particularly if they are all running a different operating system. | 17:19.01 |
| malc_ | Robin_Watts: yes it is | 17:22.34 |
| henrys | marcosw:so henrysx6 is 192.168.1.103. | 17:22.35 |
| Robin_Watts | malc_: Can you do a quick test to see if glyph_scissored ever returns 1 please? | 17:24.07 |
| | essentially whenever glyph_scissored returns 1 you should skip the hashing etc. | 17:24.25 |
| marcosw | henrys: thx | 17:25.07 |
| henrys | about to step away does it work? | 17:25.19 |
| | marcosw ^^^ | 17:25.43 |
| malc_ | Robin_Watts: yes it does | 17:25.51 |
| marcosw | yup | 17:25.54 |
| | that's what I meant by thx | 17:26.12 |
| Robin_Watts | malc_: But this doesn't save you an appreciable amount in overall time? | 17:26.16 |
| malc_ | Robin_Watts: correct | 17:26.27 |
| Robin_Watts | Either the work involved in hashing is small enough that we aren't saving much by avoiding it, or glyph_scissored is not returning 1 in enough cases. | 17:27.09 |
| | Another crap test: count the number of times glyph_scissored returns 0 and the number of times it returns 1. | 17:28.27 |
| | and print them out after each tile. | 17:28.35 |
| | and reset them to zero. | 17:28.39 |
| | We should see a believable number for each tile. | 17:29.16 |
| malc_ | Robin_Watts: this counter should be local to fz_draw_fill_text or not? | 17:31.28 |
| Robin_Watts | I'd use a global variable personally, so I could get to it from ttest.c | 17:31.56 |
| malc_ | okay | 17:32.56 |
| | heh, funny | 17:36.20 |
| | it passes most of the time | 17:36.29 |
| Robin_Watts | IT mostly returns 0? | 17:37.00 |
| malc_ | it mostly returns 1 | 17:37.31 |
| Robin_Watts | mostly returns 1 = most chars are clipped away. | 17:37.44 |
| malc_ | yep | 17:37.58 |
| | 16.25% ttest ttest [.] fz_transform_point 11.32% ttest ttest [.] fz_concat 10.67% ttest ttest [.] fz_bound_glyph | 17:38.47 |
| | 10.35% ttest ttest [.] pdf_show_string | 17:38.50 |
| | 8.39% ttest ttest [.] fz_transform_rect | 17:38.52 |
| | 6.42% ttest ttest [.] fz_draw_fill_text | 17:38.55 |
| | 6.06% ttest ttest [.] pdf_lookup_hmtx | 17:38.57 |
| | 5.58% ttest ttest [.] glyph_scissored | 17:39.00 |
| kens | OK goodnight folks | 17:40.50 |
| tsdgeos | hi guys, there's a regression when using gs9.07+libspectre to render files, it seems it only works fine when LANG=C | 17:42.38 |
| | do you know about any change from gs9.06 to 9.07 that may cause that? | 17:42.59 |
| Robin_Watts | tsdgeos: What OS are you on? | 17:43.55 |
| tsdgeos | linux | 17:44.02 |
| malc_ | that's not an os | 17:44.12 |
| tsdgeos | bunch of smart people here eh? | 17:44.33 |
| Robin_Watts | malc_: It's a family of OS, and it's close enough for what I needed. | 17:44.46 |
| malc_ | Robin_Watts: it's a kernel | 17:44.58 |
| | and sorry RMS hat just flew by and i decided to try it on | 17:45.11 |
| | comfy | 17:45.20 |
| Robin_Watts | tsdgeos: Short answer, I am not aware of any changes offhand. | 17:45.27 |
| tsdgeos | Robin_Watts: ok, thanks | 17:45.48 |
| Robin_Watts | but work has been going on to tweak unicode command line/filename handling etc, but that's mostly on windows. | 17:46.24 |
| | I am not personally familiar with libspectre. | 17:46.43 |
| tsdgeos | it's just a layer on top of gs | 17:46.56 |
| Robin_Watts | How does libspectre drive gs ? | 17:46.59 |
| | Via the command line, or via the gsapi interface? | 17:47.21 |
| tsdgeos | with the gdevdsp.h thing | 17:47.22 |
| | gsapi | 17:47.29 |
| Robin_Watts | And what differences in behaviour are you seeing? | 17:47.48 |
| tsdgeos | if i use gs9.06 it works with any LANG, if i use gs9.07 i have to specify LANG=C otherwise fails at rendering with -21 | 17:48.42 |
| | tbh not sure if -21 is an spectre error or a gs one, let me check | 17:48.55 |
| Robin_Watts | #define gs_error_undefined (-21) | 17:49.19 |
| | So I'm guessing that something that is being fed from libspectre to gs through gsapi is being interpreted differently. | 17:49.56 |
| | It could be that libspectre is sending numbers through with ,'s instead of . 's or something like that. | 17:50.45 |
| tsdgeos | yep, gs error code | 17:50.59 |
| | after calling gsapi_run_string_continue | 17:51.09 |
| Robin_Watts | If you can trap the exact command line that's being passed into gsapi, under each of the different LANGS then we can look into it. | 17:51.45 |
| tsdgeos | sure debugging it | 17:52.15 |
| | just wanted to check if you may know of anything off hand that may cause it | 17:52.28 |
| ray_laptop | tracked down the differences in some psdcmyk pages with my pdf14_clist_optimize. The value returned from the gx_concretize_ICC is totally different than with master. Have to dig into the ICC profile handling to see what's going on :-( | 18:03.05 |
| | where's mvrhel when you need him ;-) | 18:03.21 |
| Robin_Watts | ray_laptop: Was there a bug you wanted me to look at? | 18:03.42 |
| ray_laptop | Robin_Watts: not really. The icc transform of the color is coming back with a different color. Just _slightly_ different, but visible and fairly significant. I have to look to see which profiles and rendering intents it is using to form the link ;-( | 18:12.11 |
| Robin_Watts | ray_laptop: OK, I thought that maybe there were some segvs or indeterminisms in psdcmyk outstanding? | 18:12.46 |
| ray_laptop | in this case, with master, Pantone 306 CV is coming out as CMYK=[47112, 1985, 3063, 0] but with my branch I get CMYK=[39895, 0, 0, 0] | 18:14.44 |
| | Robin_Watts: I don't think it is actually indeterminate, and all the SEGV's are cured | 18:15.20 |
| Robin_Watts | ray_laptop: Ah, fab. I'll butt out then. | 18:15.43 |
| ray_laptop | Robin_Watts: np. If I need somebody to consult with, and mvrhel hasn't shown up, I'll see if you will lend a remote "ear" | 18:16.30 |
| tsdgeos_ | that was me? | 18:17.38 |
| | :D | 18:17.40 |
| ray_laptop | the actual data for the rasters are completely the same, so that's why bmpcmp doesn't gripe (I suspect it ignores the tint information in the header) | 18:17.59 |
| ray_laptop | doesn't understand what ghostbot is "thinking" | 18:18.44 |
| Robin_Watts | ray_laptop: The diff ignores them yes. | 18:18.53 |
| | tsdgeos logged in from (~root@...) | 18:19.09 |
| ray_laptop | Robin_Watts: Oh, I see that now | 18:19.28 |
| tsdgeos_ | Robin_Watts: so http://paste.kde.org/~tsdgeos/689738/ when fails and http://paste.kde.org/~tsdgeos/689744/ when works | 18:19.45 |
| | Robin_Watts: can't see any difference in what i send | 18:19.58 |
| | just that once i get back an error and in the other not | 18:20.08 |
| ray_laptop | Robin_Watts: it might be good to report that fact, even though no raster differences were found | 18:20.22 |
| tsdgeos_ | Robin_Watts: around line 700 | 18:20.28 |
| Robin_Watts | ray_laptop: Indeed. | 18:20.30 |
| ray_laptop | Robin_Watts: BTW, does bmpcmp look at all the pages of a file ? or just the first page ? | 18:21.49 |
| Robin_Watts | tsdgeos: What value of LANG are you using for the one with the error please? | 18:22.03 |
| | ray_laptop: all pages. | 18:22.15 |
| tsdgeos_ | Robin_Watts: ca_ES.UTF-8 | 18:22.22 |
| ray_laptop | Robin_Watts: thanks | 18:22.22 |
| tsdgeos_ | Robin_Watts: is the ghostcript code in git? svn? | 18:22.38 |
| Robin_Watts | tsdgeos: git | 18:23.16 |
| tsdgeos_ | ghostpdl.git ? | 18:23.43 |
| Robin_Watts | Under ca_ES, instead of '.' for decimal point, it uses ',' I believe. | 18:24.08 |
| | yes. | 18:24.16 |
| | gs is a subset of ghostpdl.git | 18:24.27 |
| tsdgeos_ | Robin_Watts: yes, ca_ES uses , | 18:24.27 |
| Robin_Watts | So, I suspect that when we call atof (or whatever), we read 141.250000 and get confused. | 18:25.07 |
| tsdgeos_ | Robin_Watts: i've already tried giving -r141,250000x141,278351 instead of -r141.250000x141.278351 | 18:25.10 |
| | didn't work | 18:25.16 |
| Robin_Watts | Bang goes that idea then. | 18:25.22 |
| | Gimme a mo to start linux here. | 18:25.48 |
| tsdgeos_ | i'll try to git bisect | 18:25.53 |
| | but not sure how lucky i'm going to be | 18:26.01 |
| | last time i tried compiling gs (which was like years ago) it was not that easy to get it up and running | 18:26.17 |
| Robin_Watts | git clone && cd ghostpdl.git && ./autogen.sh && make debug | 18:27.27 |
| tsdgeos_ | sure :D | 18:28.56 |
| | compiling was easy, but i always had stuff failing when running my compiled version | 18:29.04 |
| | can't recall what it was to be honest | 18:29.09 |
| Robin_Watts | I'm having to do a clean configure and build here cos of the source code reorganisation that just happened, so this will take a few minutes... fetching tea. | 18:31.04 |
| | tsdgeos: If you set LANG to be en_US.UTF-8 does it work? | 18:38.56 |
| tsdgeos_ | checks | 18:39.41 |
| | Robin_Watts: yes | 18:40.23 |
| Robin_Watts | Morning mvrhel_laptop. I just closed a bug of yours regarding lcms2. I hope that's OK. | 18:44.41 |
| tsdgeos_ | Robin_Watts: i wonder if is the suff like | 18:44.55 |
| | color_packet 0 get 0.299 mul | 18:44.57 |
| | that is getting not parsed fine? | 18:45.03 |
| Robin_Watts | That doesn't go in via the same encoding mechanism, so I'd hope not. | 18:46.09 |
| tsdgeos_ | Robin_Watts: make debug just finished where do i find libgs,so? | 18:46.37 |
| mvrhel_laptop | Robin_Watts: of course it is fine | 18:46.38 |
| | I was just laughing at your bacon countdown | 18:46.49 |
| Robin_Watts | :) | 18:47.35 |
| | tsdgeos: I can't reproduce it here with vanilla gs. | 18:52.55 |
| tsdgeos | Robin_Watts: i know, direct gs calls work | 18:57.39 |
| tsdgeos_ | Robin_Watts: what does build libgs.so? make debug didn't give it to me | 18:57.55 |
| | and gs/doc/Make.htm suggests make so | 18:58.07 |
| | that doesn't do anything | 18:58.12 |
| Robin_Watts | make so maybe ? | 18:58.18 |
| tsdgeos_ | no, make so says there is no rule for so | 18:59.15 |
| Robin_Watts | Are you in 'gs' or 'ghostpdl.git' ? | 19:00.49 |
| tsdgeos_ | ghostpdl | 19:01.11 |
| Robin_Watts | To make gs you need to be in gs. | 19:01.21 |
| | and you need to ./autogen.sh there too. | 19:01.28 |
| tsdgeos_ | ok | 19:01.42 |
| Robin_Watts | my apologies, I missed that stage. | 19:02.05 |
| tsdgeos_ | no worries | 19:02.14 |
| | ok, so i compiled the 9.0.6 tag and works again | 19:08.04 |
| | now i'll compile 9.0.7 will make sure it doesn't | 19:08.13 |
| | and will bisect | 19:08.16 |
| Robin_Watts | Fab, thanks. | 19:08.34 |
| mvrhel_laptop | Robin_Watts: mupdf question for you | 19:19.37 |
| | what type of clean up do I need to do with my fz_context when I have a current context and am about to open a new file. | 19:20.28 |
| Robin_Watts | mvrhel_laptop: No cleanup at all. | 19:20.43 |
| | Just use the same context. | 19:20.56 |
| mvrhel_laptop | ok. that is nice. it does currently work but I was worried I was missing a step | 19:21.03 |
| Robin_Watts | You need to fz_document_close(); | 19:21.06 |
| | or fz_close_document, or whatever it is. | 19:21.13 |
| mvrhel_laptop | ah ok | 19:21.19 |
| | on fz_document | 19:21.38 |
| | gotcha | 19:21.42 |
| Robin_Watts | That gets rid of the document, but the context can be reused. | 19:21.44 |
| | yeah. | 19:21.45 |
| mvrhel_laptop | great | 19:21.50 |
| | thanks | 19:21.51 |
| Robin_Watts | np. | 19:21.54 |
| TomRoberts | I have just tried mupdf. It's FANTASTIC! I'm using it on a Raspberry Pi, which is a wimpy CPU, and I could fairly easily put PDF rendering into a background thread so pageDown is fast (I', displaying music for real-time performance). | 19:52.14 |
| Robin_Watts | TomRoberts: Fab. | 19:52.26 |
| TomRoberts | I'm awaiting a hardware part; when the HW is done I'll post it to the RasPi blog as a project. My code is open source. | 19:55.12 |
| Robin_Watts | TomRoberts: I shall look forward to reading about it. | 19:55.38 |
| TomRoberts | Thank you so much for a powerful PDF rendering engine. Cropping and annotations done in Mac OS X preview are handled perfectly, so each page is expanded to fit the window. | 19:56.31 |
| | I could never have done this myself. | 19:56.44 |
| Robin_Watts | Is this an electronic music stand project? | 19:57.05 |
| TomRoberts | Yes. | 19:57.12 |
| | The RasPi is munted on the back of a thin monitor, and it fits on my piano just fine. | 19:57.49 |
| Robin_Watts | I think I heard about this before. I mentioned it to my wife who is a professional harpsichordist. | 19:58.05 |
| | She said "I'd never trust that, it'd crash in the middle of a performance" | 19:58.22 |
| | :) | 19:58.25 |
| TomRoberts | A Bili pedal does PageUp and PageDown; a wireless mouse completes the system (open file, etc.). | 19:58.27 |
| Robin_Watts | TomRoberts: So next stage is to listen to the music as it's played so it knows where you are in the piece, and page flips automatically? | 19:59.06 |
| TomRoberts | I'm a rehearsal accompanist for a chorus, and always bring paper. I don't have enough experience to trust it for a performance, but I don't expect that to be a problem. | 19:59.30 |
| Robin_Watts | You'd not be doing it with PDF in that case i guess. | 19:59.37 |
| TomRoberts | Yes, my code displays the music from PDF. | 19:59.59 |
| Robin_Watts | I'm sure it's one of those things that will be trusted once it's been around for long enough. | 20:00.06 |
| TomRoberts | Yes. | 20:00.17 |
| Robin_Watts | I mean, if you had the stand listen in to the music to know when to turn pages etc, you'd need the music in a different representation than just pdf. | 20:00.44 |
| TomRoberts | My system has been up for days at a time, but mostly idle. I've only used it for one rehearsal so far, and the HW is not complete. | 20:00.50 |
| | (needs 12V -> 5V, for now I use 2 power supplies) | 20:01.10 |
| | Again, THANKS! | 20:01.35 |
| Robin_Watts | you're welcome. Thanks for telling us about it. | 20:01.49 |
| TomRoberts | The stand does not listen, I use a foot pedal to turn pages. MUCH better than paper. | 20:02.08 |
| Robin_Watts | I was suggesting that it could listen in a future version. | 20:02.50 |
| TomRoberts | Listening is a rather advanced AI project. Remarkably, I have done real-time speech recognition as Bell Labs, but don't think I want to tackle listening to music and comparing it to images of the score... | 20:03.44 |
| ray_laptop | when to turn the page would be a heuristic nightmare, IMHO. | 20:03.58 |
| Robin_Watts | TomRoberts, no, that's what I mean by having the data in another format. | 20:04.12 |
| TomRoberts | Yes. receiving a PageDown from the pedal is definitive. | 20:04.25 |
| ray_laptop | when I played, even when I had a page turner, I would nod or have to practice with them a lot to make it the way I wanted it | 20:04.53 |
| | it was usually simpler to just memorize the whole piece ;-) | 20:05.25 |
| TomRoberts | Yes, a human pae turner needs to be trained a bit, and cooperation is the name fo the game; I have done both. The pedal is good enough for me. | 20:05.35 |
| Robin_Watts | ray_laptop: If you could get it to the stage where it would reliably know where you were, you could set the page turn position for each page. | 20:05.43 |
| | but it sounds like a PhD project to me. | 20:05.53 |
| ray_laptop | but then, that was just clarinet and sax -- not quite as many notes at once as on a kb | 20:06.02 |
| TomRoberts | Yes. My system responds to PageDown in less than 100ms and is visibly instant; but I want to see the next measure before I need to play it. | 20:06.45 |
| ray_laptop | cust 532 comes back out of the woodwork :-( | 20:06.47 |
| TomRoberts | Also, I doubt the RasPi has enough horsepower to do the signal processing to listen to music. Yes, listening and turning pages would be a very advanced AI project. | 20:08.07 |
| | bye. | 20:11.02 |
| Robin_Watts | They're all spoiled with the horsepower of the Raspberry Pi. My first ARM was 8Mhz, and that was BLINDINGLY fast at the time. | 20:12.24 |
| ray_laptop | Back in college, we did real-time ECG analysis (to spot irregular beats) and that was on a PDP-11/20. Instruction timing ranged from 1.5 microseconds to 3.9 microseconds depending on how many memory references were required | 20:17.23 |
| | time for a lunch break... | 20:20.04 |
| | mvrhel_laptop: Are you available ? | 21:33.05 |
| mvrhel_laptop | I am here ray_laptop working on some winRT UI stuff | 21:33.32 |
| ray_laptop | mvrhel_laptop: I have a bug where the separation spot_equivalent_cmyk_color is getting different numbers. | 21:34.45 |
| mvrhel_laptop | ray_laptop; ok please assign to me and I will look it over on my flight | 21:35.12 |
| ray_laptop | It looks like the 'render_cond' is bogus (for BOTH my branch and the master) | 21:35.28 |
| mvrhel_laptop | ray_laptop: where are you talking about? | 21:37.42 |
| ray_laptop | I see in capture_spot_equivavlent colors where it fills in the device_profile array in the temp_profile, but I don't see it touching render_cond | 21:37.43 |
| | so when it gets down into gsicc_get_link it takes different paths. | 21:38.23 |
| mvrhel_laptop | ray_laptop: I don't know where you are in the code | 21:39.20 |
| | oh capture_spot_equivavlent colors | 21:39.39 |
| | hold on | 21:39.42 |
| ray_laptop | due to the render_cond.rendering_intent being different | 21:41.20 |
| mvrhel_laptop | ok so the rendering intent needed to be set on the temp_device | 21:42.57 |
| ray_laptop | also it looks like there is garbage in the devicegraytok but I haven't traced far enough to see if that makes a differernce | 21:43.02 |
| mvrhel_laptop | from rend_cond | 21:43.03 |
| ray_laptop | mvrhel_laptop: OK, so what's a good "default" ? | 21:43.26 |
| mvrhel_laptop | use render_cond | 21:43.37 |
| ray_laptop | given that we are just trying to get the spot equivalent ? | 21:43.49 |
| mvrhel_laptop | it that is what the device is going to do then yes. we are using the devices profile | 21:44.33 |
| | ray_laptop: why would you do something different | 21:44.49 |
| ray_laptop | mvrhel_laptop: so I should just copy rendercond from the "real" device ? | 21:45.05 |
| mvrhel_laptop | s/it that/if that/ | 21:45.08 |
| | ray_laptop: you have it in the variable render_cond | 21:45.25 |
| | line 463 | 21:45.30 |
| | when you got curr_output_profile | 21:45.42 |
| ray_laptop | mvrhel_laptop: that is { 8, 8, 8, 0, 0, 0, 0 } is that reasonable ? | 21:46.29 |
| | (usually VS shows me gsRINOTSPECIFIED) | 21:47.29 |
| mvrhel_laptop | yes. not specified is correct | 21:48.36 |
| | if no one has specified it for the device | 21:49.05 |
| | that looks like the default settings | 21:50.06 |
| ray_laptop | mvrhel_laptop: hmm.. the 'get_profile' returned something that looks bogus | 21:50.07 |
| | Oh, sorry 8 _is_ NOTSPECIFIED. VS just didn't decode it for me | 21:51.18 |
| | strange (clever) use of an enum to have it compute the masks (_OR elements) :-) | 21:52.55 |
| tsdgeos | Robin_Watts: still there? | 21:53.56 |
| mvrhel_laptop | ray_laptop: that could have been done simpler. at least I used enumeration and not magic numbers... | 21:53.57 |
| | ;) | 21:54.06 |
| ray_laptop | so yet another indeterminate behaviour bug. sigh... | 21:54.14 |
| | mvrhel_laptop: YES. THANK YOU FOR THAT. But I thought you were going to get rid of the magic numbers in the pdf14 compositor stuff | 21:55.07 |
| mvrhel_laptop | ray_laptop: I thought we did. or was that one of those cases where I thought about it and it never got done | 21:55.44 |
| ray_laptop | I'm quite surprised that this didn't show up more often before. | 21:55.45 |
| mvrhel_laptop | ray_laptop: yes. I am surprised at the number of issues you stumbled upon. I don't know why I did not see them in the regression testing | 21:56.13 |
| ray_laptop | mvrhel_laptop: gxclrast.c following if (cbp[0] == cmd_opv_extend && cbp[1] == cmd_opv_ext_create_compositor) | 21:56.59 |
| | line 1566 forward | 21:57.42 |
| mvrhel_laptop | oh yes. all the return codes | 21:57.54 |
| ray_laptop | mvrhel_laptop: should I open a P1 bug for it ;-) | 21:58.36 |
| | mvrhel_laptop: and assign it to henrys ??? ;-) | 21:59.15 |
| mvrhel_laptop | why not. it will only take a short time to fix. maybe I will do that on the flight. a break from winRT for a bit | 21:59.16 |
| | ha | 21:59.19 |
| | bbiaw | 22:12.24 |
| ray_laptop | mvrhel_laptop: OK. Running that. Colors look more reasonable :-) | 22:25.11 |
| mvrhel_laptop | ray_laptop: great | 22:25.21 |
| ray_laptop | At least this explains why only psdcmyk was a problem. tiffsep cmyk composite would be wrong as well, of course. | 22:28.20 |
| | not too many other devices care about the equivalent cmyk | 22:28.44 |
| | mvrhel_laptop: thanks for the consult | 22:29.22 |
| mvrhel_laptop | ray_laptop: glad that it worked out | 22:38.22 |
| ray_laptop | mvrhel_laptop: well, running the regression now -- I'll let you know if I trip over anything else | 22:43.33 |
| vtorri | hey | 23:16.43 |
| ghostbot | moin moin, vtorri | 23:16.43 |
| vtorri | about mupdf, have you tried to compile it with : | 23:17.08 |
| | -Wextra -Wshadow | 23:17.15 |
| | ? | 23:17.17 |
| | if no, what about doing it and fixing warnings ? | 23:17.40 |
| Robin_Watts | tsdgeos: I am away from the computer for a bit. | 23:24.24 |
| | but if you have found stuff, say so, and I'll read the logs when I get back. | 23:24.38 |
| tsdgeos | Robin_Watts: i found the commit that breaks it | 23:25.00 |
| | but it's a 22K line diff commit :D | 23:25.07 |
| | let me boot the virtual machine | 23:25.20 |
| Robin_Watts | tsdgeos: Just give me the SHA and I'll look tomorrow. Gotta go, sorry! | 23:26.11 |
| tsdgeos_ | Robin_Watts: so a971121e9e50c672908f1b3185f42d497adf0b02 works and 58937f6debfbed7675a0ce5cb8d0aa629e3fa7b8 fails | 23:31.51 |
| tsdgeos | i'll be here tomorrow too in case you want me to try something | 23:32.26 |
| ray_laptop | should have queued up the bmpcmp before leaving :-( | 23:51.54 |
| | MANY more differences than I expeccted, but getting rid of a UMR is bound to cause (one time) differences. I wonder why it was so consistent previously. Maybe just the stack contents in the critical few bytes | 23:53.06 |
| | not too bad. almost all "no difference found" as I expected since bmpcmp doesn't look at the spot color map | 23:59.58 |
| | Forward 1 day (to 2013/03/08)>>> | |
IRC Logs