| | <<<Back 1 day (to 2015/09/28) | 20150929 |
| tor8 | Robin_Watts: so, any ideas about this GlyphLessFont? | 08:39.22 |
| srini | hello all... mupdf developers online? | 08:48.42 |
| tor8 | srini: yes. | 08:53.09 |
| Robin_Watts | Morning | 08:54.08 |
| | tor8: Not really. | 08:54.25 |
| | I couldn't see how fonts *ever* looked at the default width for the advance. | 08:54.58 |
| tor8 | pdf_lookup_hmtx is used when placing the text | 08:55.48 |
| | bits of the horizontal metrics are used when creating a width_table for substitute fonts (so we can squish and stretch the rendered glyph widths to match the PDF metrics) | 08:56.25 |
| | it just occurred to me that it might be easier to add in fake space characters in the interpreter when it spots a sudden horizontal movement | 08:57.27 |
| | and then never try to guess at spaces in the structured text extraction | 08:57.44 |
| | we have provisions for characters with no corresponding glyph in the fz_text structure | 08:58.19 |
| chrisl | You have the Widths array, shouldn't you consult that for the glyph width? | 08:59.36 |
| tor8 | we only use it for XPS currently, since XPS gives both the unicode and glyph index arrays separately | 08:59.57 |
| | chrisl: we only have the Widths array for the PDF interpreter | 09:00.15 |
| | we don't keep the PDF font widths and encoding tables beyond the device interface layer | 09:00.40 |
| | except in the case where we bake it down into a table for substitute fonts | 09:01.07 |
| chrisl | But if you use the spacing as part of the heuristic for text output, surely you need access to the actual applied spacing to make it reliable | 09:01.40 |
| Robin_Watts | tor8: Adding extra spaces sounds like a really bad idea. | 09:02.17 |
| tor8 | well, in general the applied spacing can be inferred by looking at the glyph widths. | 09:02.49 |
| | and, in general, the PDF Widths and the actual freetype widths tend to match | 09:03.14 |
| Robin_Watts | It breaks the whole idea of us gluing glyphs back together. | 09:03.20 |
| chrisl | There are *many* PDFs out there what the metrics in the Widths arrays don't match the widths in the fonts | 09:03.24 |
| Robin_Watts | tor8: It's a massive step backwards. | 09:03.28 |
| tor8 | and when using substitute fonts, we use the PDF widths array | 09:03.31 |
| Robin_Watts | The width information should be pickled into the fz_font. | 09:03.42 |
| tor8 | now, we *can* pickle the font widths into the fz_font structure for *all* fonts, not just the substitute fonts | 09:04.10 |
| | in which case this file almost works | 09:04.16 |
| | it also needs to pickle the "DW" | 09:04.31 |
| Robin_Watts | yes. | 09:04.42 |
| chrisl | And W for CIDFonts..... | 09:04.47 |
| tor8 | but doing that, we would fail in other cases where the PDF file doesn't provide a full Widths array and falls back to actual font widths (or is that even possible?) | 09:05.05 |
| chrisl | That is not allowed in the spec, but does happen | 09:05.28 |
| | Just like the Widths array is supposed to match the widths in the font, but often doesn't | 09:05.48 |
| tor8 | chrisl: yeah... | 09:06.05 |
| Robin_Watts | chrisl: Wooah. The Widths array does NOT have to match the widths in the font. | 09:06.06 |
| chrisl | Robin_Watts: yes it does | 09:06.19 |
| Robin_Watts | The Widths array is (IIRC) specifically stated to override the widths in the font. | 09:06.31 |
| chrisl | Nope, they are supposed to match | 09:06.39 |
| tor8 | you're both right :) | 09:07.50 |
| | they are supposed to match, but then, implementation note... | 09:08.05 |
| | Acrobat 5.0 and later viewers use the glyph widths stored in the font dic- | 09:08.17 |
| | tionary to override the widths of glyphs in the font program itself, which | 09:08.17 |
| | improves the consistency of the display and printing of the document. | 09:08.17 |
| | This addresses the situation in which the font program used by the viewer | 09:08.17 |
| chrisl | Well, yes...... | 09:08.19 |
| kens | I'm fairly sure an older version of the spec said the font withs overrode the Widths array and the spec wsas changed to follow what Acrobat actually does | 09:08.26 |
| chrisl | It's academic really, since we *know* Acrobat gives priority to the Widths array | 09:09.01 |
| kens | And regrdless of what the spec *says* 'Acrobat can view it'..... | 09:09.31 |
| chrisl | But also doesn't complain about a missing Widths array, despite it being a required entry | 09:10.03 |
| srini | in the html extraction the I am finding that the spans are repeating... eg... <span class='1x'>text</span><span class='1x'> here</span> .... is there a way to avoid these adjacent spans? | 09:10.18 |
| kens | Its quite an achievement to get Acrobat to complain about anythign very much, if it even looks remotely like a PDF file | 09:10.38 |
| chrisl | I do remember trying a truncated Widths array, but I can't remember what the outcome was..... | 09:11.25 |
| kens | srini possibly that's exactly what's in the PDF file, artifical emboldening can look like that, or stroke then fill. Its hard to say without seeing the PDF file | 09:11.29 |
| tor8 | srini: any time any aspect of the font changes, there will be a new 'span' | 09:13.44 |
| | even for changes that don't actually matter for the HTML output | 09:14.06 |
| | you could walk the structured text structures and do it in your own code if want a different output | 09:14.59 |
| | the HTML extraction is pretty simple code really | 09:15.05 |
| | Robin_Watts: well, I have a fix but I fear it will break for the base-14 fonts :/ | 09:15.49 |
| | since those fonts don't need a Widths array at all for anything | 09:16.02 |
| Robin_Watts | tor8: So we should look at 'Widths' if it's there. If it's not (or we're not covered) look at DW. | 09:16.32 |
| | If neither of those are there, look at the actual font width. | 09:16.47 |
| chrisl | IIRC, the Widths array is optional for base-14 fonts | 09:17.06 |
| Robin_Watts | chrisl: Yes, AIUI, too. | 09:17.39 |
| | but I *hope* our clone fonts match the widths arrays that would be there if they weren't optional. | 09:18.02 |
| chrisl | The problem is, at least some producers intentionally write Widths arrays that differ from the actual font widths, for their own nefarious reasons | 09:19.11 |
| tor8 | ah, actually it looks like it might work for base-14 as well | 09:19.43 |
| | we create a fake Widths table from the freetype glyphs if a simple font is missing the /Widths | 09:20.05 |
| srini | tor8, I am not from programming .. I tried some xslt stuff but did not a proper solution for that... can there be some help pls? | 09:54.30 |
| | logically is the | 09:55.19 |
| | *sorry | 09:55.24 |
| | logically if the the current span class and the previous span class are same do not start a new span.... | 09:55.53 |
| Robin_Watts | srini: Are you using gs or mupdf? | 09:57.24 |
| srini | Robin_Watts, mupdf | 09:57.42 |
| Robin_Watts | Can you provide an example file? | 09:58.02 |
| srini | sure... will create a link | 09:58.31 |
| | Robin_Watts, how do I share a pdf file? | 10:01.50 |
| Robin_Watts | Make a bug on bugs.ghostscript.com and attach the file? | 10:02.15 |
| srini | sure... | 10:02.25 |
| | Robin_Watts, 696230 | 10:05.25 |
| tor8 | Robin_Watts: commit on tor/master to always create a glyph width table | 10:08.38 |
| | and respect the DW in said table | 10:08.47 |
| Robin_Watts | tor8: Commit seems fine. Have you tested it with the file in the bug ? | 10:45.51 |
| tor8 | Robin_Watts: yes. we get no spurious spaces. but we also get no added spaces... but I'd blame that on the heuristics not working well... | 10:47.33 |
| | no spaces where we should have, I mean | 10:47.49 |
| Robin_Watts | tor8: hmm. That deserves at least a quick check I think. | 10:48.04 |
| tor8 | the text order looks reasonable, so I don't know why we don't detect a space between "4X" and "35067" for instance | 10:49.15 |
| | Robin_Watts: ah. the matrix changes (different font size) so we never try to add a space | 10:53.58 |
| | if I tweak that, we get a space between "4X 35067" but then the big gap is run right onto the end of the same span | 10:56.20 |
| Robin_Watts | tor8: I'm in the middle of a rebase at the moment :( | 11:01.11 |
| sandstrom | I'm using Ghostscript to convert PDFs to images, and it has worked great. However, I've run into trouble with PDFs from 'Microsoft PDF-printer', which seems to be bundled with Windows 10. They turn out mostly blank, no text included. Gettings errors like this: 'Warning: can't process font stream, loading font by the name.\nCan't find CID font "CIDFont+F1".\nAttempting to substitute CID font /Adobe-Identity for /CIDFont+F1, see | 11:13.39 |
| | doc/Use.htm#CIDFontSubstitution\nThe substitute CID font "Adobe-Identity" is not provided either. attempting to use fallback CIDFont.See doc/Use.htm#CIDFontSubstitution. | 11:13.39 |
| kens | Try using a more recent version of Ghostscript. | 11:14.02 |
| sandstrom | (sorry for multi-line); anyone who has had similar issues with Windows 10 generated PDFs? | 11:14.06 |
| | kens I'm on 9.15, is that recent enough? | 11:14.16 |
| kens | Also look at the prop-erties of the device and tell it to embed fonts. | 11:14.16 |
| | sandstrom : probably not | 11:14.25 |
| sandstrom | kens I'm afraid getting Microsoft to fix this is beyond my capacity :) | 11:14.51 |
| kens | Your basic problem is that the fonts aren't embedded in the PDF file, so Ghostscript looks for a substitute (and they are CIDFonts) | 11:14.53 |
| | If you use a recent version of Ghostscript we will substitute a fallback font (DroidSansFallback) for a missing CIDFont | 11:15.34 |
| | Howerve3r the correct answer in all these cases is to embed teh font. | 11:15.46 |
| sandstrom | kens so 9.16 should solve this? Is there a way to solve it under 9.15? Is the issue that I'm the fallback CIDfont? | 11:15.46 |
| kens | Without seeing your PDF file I can't promise any version will work. The current version is 9.16 but we are at RC2 with 9.18 | 11:16.23 |
| sandstrom | I understand that the root cause is outside Ghostscript (it has worked well with other, non-windows PDFs). Sadly Windows 10 has a decent user-adoption curve, these show up even though I'd prefer if they didn't :) | 11:16.59 |
| kens | If you are creating the files yourself, then you need to alter the printer settings to embed the fonts. THs 'might' be something like 'optimise for portability' | 11:16.59 |
| | If the fotns are not embedded you are *never* going to get the 'right' answer, just a flavour of wrongness | 11:17.30 |
| | I don't currently have a copy of Windows 10 so I can't reccomend anythign further than that. | 11:18.03 |
| chrisl | That sounds like the the CIDFont stream might actually be broken | 11:18.29 |
| kens | It is possible | 11:18.35 |
| sandstrom | here is a direct-download link to one example (standard wikipedia print via Windows 10 pdf-printer): https://www.dropbox.com/s/m2b3atvbqfmnac7/w10-2.pdf?dl=1 | 11:19.02 |
| kens | Or we could just have a problem with it, whch is why I sugegst trying the most recent version (9.18 RC2) | 11:19.05 |
| | fetches file | 11:19.16 |
| | Well the fonts are embedded | 11:19.39 |
| sandstrom | (I managed to get Windows 10 running in my VM, to generate the file above) | 11:19.39 |
| chrisl | I'm heading out for a bit - let me know if you need me to look it | 11:19.49 |
| kens | well we have a problem with the font, not sure why. | 11:20.18 |
| sandstrom | Ghostscript 9.15 (2014-09-22), running on Ubuntu 14.04 | 11:20.27 |
| kens | 9.18 renders the file but the text is incorrect, obviously because its using the fallback font | 11:20.37 |
| sandstrom | (if that is useful) | 11:20.38 |
| tor8 | kens: mupdf doesn't seem to have the same problems with the file | 11:20.40 |
| kens | tor8 : I wa goping to try that next | 11:20.50 |
| | Don't forget GS processes the fonts extensively before passing to FT | 11:21.02 |
| | With DroidSans the basic text is fine, but the accented characters are not | 11:21.26 |
| | Not too surprising | 11:21.31 |
| tor8 | kens: could the '+' in the font name be confusing it? expecting the usual 6-byte subset font suffix or something like that? | 11:21.42 |
| kens | tor8 it 'shouldn't be a problem | 11:22.02 |
| | But you know, PDF :-( | 11:22.14 |
| | sandstrom : I'm i the middle of something else I'd suggest you open a bug report and attache the file to tit, then we won't forget about t | 11:22.36 |
| sandstrom | kens okay, I will file a bug. Thanks for looking into it. So the stopgap may be mupdf, or trying with 9.18 RC2? | 11:23.50 |
| kens | you cna use Mupdf, RC2 will still get some of your text wrong. | 11:24.54 |
| | I may have time to take a closer look this afternoon | 11:25.55 |
| henrys | wow urw agreed to it all or our requests even the extending the embedded exclusion - great new | 13:41.48 |
| | I was so excited I used too many words | 13:42.07 |
| kens | good news indeed | 13:43.10 |
| tor8 | henrys: fab! | 13:58.10 |
| henrys | meeting in a few minutes | 14:28.01 |
| mvrhel_laptop_ | oh that is good news about urw | 14:28.33 |
| henrys | hope they finish before GG figures out what they are doing ;-) | 14:29.09 |
| mvrhel_laptop_ | :) | 14:29.17 |
| henrys | so yeah good start to the meeting. URW is okay with our work request | 14:32.56 |
| | the other big thing this week is release testing. I've been looking at linux gs, how much windows testing have we been doing? Lots of changes this time. | 14:33.52 |
| kens | Well, I always run on Windows..... | 14:34.08 |
| mvrhel_laptop | me too | 14:34.36 |
| henrys | but testing like different COMPILE_INIT setting etc. stuff related to the big build change. | 14:34.52 |
| chrisl | kens: fix for the Windows 10 PDF file CIDFont problem: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=8347f653 | 14:34.59 |
| marcosw1 | henrys: I don't do any windows testing. I know we've talked about adding a windows machine to do regression testing but I haven't done so. | 14:35.12 |
| chrisl | kens: fix for the Windows 10 PDF file CIDFont problem: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=8347f653 | 14:35.54 |
| henrys | marcosw1: I'm not using mac as much these days are you testing that? | 14:36.05 |
| kens | chrisl that was quick, not even had a chance ot look at the problem yet :) | 14:36.18 |
| chrisl | kens: wasn't terribly hard! | 14:36.31 |
| marcosw1 | yes. I run a nightly regression test on my MacPro. | 14:36.32 |
| kens | Hmm I see.... | 14:36.41 |
| | chrisl if it passes cluster test then push it, I can't see a problem with it offhand | 14:37.06 |
| chrisl | kens: I'll do the clusterpush in a moment | 14:37.26 |
| kens | I'm somewhat surprised it hasn't come up before | 14:37.35 |
| henrys | anyway I think it's a good idea to do a bit more testing with this release configuration wise, teesting different targets etc. that's what I'm doing in linux with it. | 14:37.51 |
| marcosw1 | chrisl: the rc2 testing is nearly done (about 6 minutes remaining). So far everything looks good for the release. | 14:38.24 |
| chrisl | henrys: it's a bit late in the day for that...... | 14:38.30 |
| | Robin_Watts: Some tweaks to gdevplib.c to fix device initialisation, reduce warnings....: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=d69af9974 | 14:39.37 |
| kens | marcosw1 in case its not obvious, I'm not doing anythgin at the moment with bug #696200 as I cannot create an intermediate PDF file that matches the customer's one. Not even using 9.15and the cusotmer's command line. Since that's where the problem occurs, I need to be able to reproduce that to fix it | 14:39.49 |
| | henrys; ran into a problemiwth PJL, it seems that we can't do the PJL in a separate file as the interpreter r4esets the PJL state whenever it completes reading a file..... | 14:40.29 |
| | The only further solution I can see is to special case hte pdfmarks in pl# | 14:40.53 |
| marcosw1 | kens: Does the pdf file you create result in a valid pdf/a-1b file when run through ghostscript? | 14:40.57 |
| kens | marcosw: 1 yes | 14:41.04 |
| | The problem is the missing font in the intermediate file | 14:41.19 |
| henrys | chrisl, marcosw: I'd vote for extending the rc on this release. | 14:41.22 |
| kens | If the font is missing, then the resultign file is not valid PDF/A | 14:41.37 |
| marcosw1 | kens: go ahead and assign the bug to me. If I can't get anywhere I'll contact the customer. | 14:41.39 |
| rayjj | sorry, I'm late, and I won't be back until about 8 or so -- I'll check the logs and respond then | 14:41.40 |
| fredross-perry | Robin, Joseph: I reworked my repo so there's now just two commits, one for proofing, and one for iCloud. | 14:41.41 |
| henrys | has anyone run compile_inits 0 on windows for this release? | 14:41.47 |
| kens | marcosw1 OK thanks | 14:41.49 |
| Robin_Watts | fredross-perry: Yeah, I saw. | 14:42.09 |
| fredross-perry | k | 14:42.15 |
| Robin_Watts | There are some line ending issues. | 14:42.16 |
| chrisl | henrys: extending it for what purpose? The only people who ever test the release candidates have done so...... | 14:42.17 |
| Robin_Watts | and the commit messages are a bit screwy. | 14:42.27 |
| rayjj | I have to take my youngest to school yet, and all three were moving slow, so I was running late. | 14:42.30 |
| Robin_Watts | I've been playing with your commits from yesterday. | 14:42.40 |
| henrys | chrisl: I'm talking about the staff testing it. | 14:42.44 |
| kens | I have not tried compile_inits=0 on Windows no | 14:43.02 |
| | I tend to use the installer and test that | 14:43.12 |
| chrisl | henrys: only you, kens and me ever test our release candidates | 14:43.12 |
| henrys | I'm still working on my 135 possible targets ;-) | 14:43.26 |
| | It think I'm up to 47 | 14:43.37 |
| chrisl | Use the documented ones | 14:44.01 |
| henrys | if everyone is comfortable with a release I'll shut up... | 14:44.15 |
| marcosw1 | rayjj: peeved is still running very slow. I'm thinking of taking it out of the cluster until it's back to normal. | 14:44.31 |
| chrisl | henrys: Well, I would like more testing to be done, but I just don't see it happening | 14:44.49 |
| henrys | kens: so there is SET one job and DEFAULT which sticks across jobs right? are you using SET? | 14:45.10 |
| kens | Yes I was using SET | 14:45.31 |
| henrys | kens: it does not save across processes | 14:45.40 |
| kens | I didn't really want it to persist across jobs | 14:45.42 |
| jogux | fredross-perry: great, thanks - still deep in stuff, will try and look in a few days time. | 14:45.46 |
| kens | henrys it doesn't sae across files. | 14:45.52 |
| | 3every time we open a file it resets the PJL state to the default (which can change of coure) | 14:46.16 |
| marcosw1 | henrys: how did you arrive at 135 targets? | 14:46.26 |
| henrys | bash has a completion thing for make | 14:46.45 |
| | kens: that's wrong it shouldn't do that. | 14:47.13 |
| kens | henrys it definitely does | 14:47.26 |
| henrys | tor8: release? | 14:47.29 |
| kens | If I run a file which contains ony PJL then run a file whcih contains PCL, then at the end of the PJL file, the environment is reset, before the PCL file is run | 14:47.57 |
| henrys | kens: the "SET" environment should be reset, "DEFAULT" should not | 14:48.32 |
| kens | Yes, that's what's happening | 14:48.43 |
| | It resets to the default | 14:48.48 |
| | I *could* use DEFAULT but thaqt would mean the stuff would get run multiple times | 14:49.04 |
| | Which might be unfortunate | 14:49.21 |
| henrys | that's exactly what PJL is supposed to do according to the spec and printer. I don't understand what you are proposing? | 14:49.34 |
| kens | I don't have a proposal, just saying | 14:49.44 |
| henrys | kens: I guess we could have a "custom thing" for this that behaves differently. | 14:50.29 |
| kens | That's the only solution I can think of | 14:50.41 |
| tor8 | henrys: soon-ish. we've been doing some bug scrubbing. | 14:51.04 |
| kens | My feeling at the moment is to use DEFAULT, but cleaqr it on first use | 14:51.04 |
| Robin_Watts | Apologies, my phone line died for a few minutes there. | 14:51.18 |
| kens | But this was from Saturday and I've forgotten it again :-( | 14:51.19 |
| henrys | Robin_Watts: funny everyone seems to be bouncing in and out. | 14:51.32 |
| kens | henrys as long as I'm not missing somethign I'll go back again, ust wanted to check ths was expected | 14:51.49 |
| marcosw1 | Robin_Watts: you still using a modem? | 14:52.10 |
| Robin_Watts | marcosw1: ADSL. | 14:52.22 |
| henrys | ny fiber is late supposed to be here by now. | 14:52.38 |
| Robin_Watts | Fibre is coming this century apparently. | 14:52.44 |
| henrys | s/ny/my | 14:52.44 |
| kens | Techncally I can get fibre to the cabinet here | 14:53.09 |
| | Haven't tried to actually request it yet | 14:53.22 |
| Robin_Watts | fredross-perry: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=shortlog;h=refs/heads/fred_fix | 14:53.33 |
| | That's your branch from yesterday, with me having juggled the commits about a bit. | 14:53.48 |
| henrys | tor8: any ideas schedule wise. I need to tell miles when the newsletter witl be done or it really wouldn't matter. | 14:54.00 |
| Robin_Watts | and tweaked the commit messages into the appropriate format. | 14:54.03 |
| tor8 | Robin_Watts: how are the mobile versions in terms of release readiness? | 14:54.47 |
| Robin_Watts | tor8: Not a clue. I've had my head up SOT for the past 3 months mostly. | 14:55.05 |
| tor8 | desktop wise I think we could push a release week after next | 14:55.06 |
| henrys | chrisl: I'm going to think about and talk to marcos about automated configuration testing for releases on different platforms. We gotta do better at this. | 14:55.12 |
| tor8 | Robin_Watts: right. and I've no clue either ... vacation and not caring about mobile stuff :) | 14:55.30 |
| chrisl | henrys: what's changed since the last time we talked about that? | 14:55.40 |
| fredross-perry | Robin_Watts: are you going to go with that then? | 14:55.44 |
| jogux | kens: fibre to the cabinet is a huge upgrade, well worth it | 14:55.53 |
| Robin_Watts | tor8: I think that mobile wise we're as good as we ever are. No massive new features, no massive new bugs. | 14:56.03 |
| | fredross-perry: Almost. We can talk after the meeting. | 14:56.15 |
| fredross-perry | ok | 14:56.21 |
| kens | jogux, not sure I use enough bandwidth to be worthwhile. And still limited by my internal network speed | 14:56.27 |
| Robin_Watts | chrisl: Those changes look plausible. | 14:56.40 |
| kens | henrys, one last thing. I'm not sure what to do about bug #696224, its not a pdfwrite problem as such. The pxlcolor device is doing something 'different' with 'text' (could be bitmaps) and filled paths, which results in ROPS 'sometimes'. Probably it shouldn't do that, but I've no idea how much we care. The 'problem' is that some PCL-compatible printers don't seem to implemenbt these ROPs | 14:56.53 |
| chrisl | Robin_Watts: Thanks | 14:56.54 |
| henrys | chrisl: I would fear your build changes could interact with things like environment variable settings, compile init changes, lots of stuff that we should be testing every build anyway | 14:57.07 |
| | s/build/release | 14:57.18 |
| chrisl | henrys: we do test compile_inits=0 every release | 14:57.38 |
| henrys | not for pcl, I can assure you of that. | 14:57.55 |
| chrisl | Well, that's because PCL didn't really support it at all | 14:58.16 |
| marcosw1 | chrisl: technically we test compile_inits=0 every week. | 14:58.29 |
| tor8 | Robin_Watts: what about the big iOS 9 update that just dropped? | 14:59.10 |
| Robin_Watts | tor8: I care not for iOS. | 14:59.20 |
| | We need to decide if we want to put gproof into the standard mupdf release. | 14:59.45 |
| | I'm thinking not. | 14:59.53 |
| henrys | marcosw1: oh I didn't know you had something for that, but I would like to hit various configuration option and env variables. | 14:59.58 |
| fredross-perry | what are the pros/cons? | 15:00.14 |
| Robin_Watts | fredross-perry: I don't want to have to ship a copy of gs in every copy of mupdf :) | 15:00.30 |
| henrys | fredross-perry: of testing? ;-) | 15:00.31 |
| mvrhel_laptop | Robin_Watts: I agree. Just leave gsproof as a compile option | 15:00.33 |
| Robin_Watts | It should be enabled if we 'SUPPORT_GPROOF=yes' when we make, but not otherwise. | 15:00.59 |
| fredross-perry | henrys: no, of including gproof in the standard mupdf release | 15:01.08 |
| chrisl | henrys: the biggest problem, if we set off down that path, is where do we stop? | 15:01.13 |
| henrys | fredross-perry: joking | 15:01.16 |
| fredross-perry | sorry, humor-impaired | 15:01.29 |
| jogux | tor8: from what I tried, mupdf is okay running on iOS 9 and afaicr building with the iOS 9 SDK | 15:01.32 |
| tor8 | jogux: great, thanks! | 15:01.41 |
| Robin_Watts | fredross-perry: 99.9% of mupdf on android users won't care about gproof. | 15:01.44 |
| fredross-perry | Robin_Watts: sure | 15:01.57 |
| jogux | tor8: if you want to prod me when the release is ready I could do the itunes upload. I'll need to update the cocoapod thing too I believe. | 15:02.32 |
| henrys | mvrhel_laptop: you have a nexus right? were you able to reproduce the white tile problem I reported there. If not let's just forget about it my tablet is flaky anyway. | 15:03.33 |
| | mvrhel_laptop: it happens with altona visual at 300 and 600 dpi for me. | 15:04.07 |
| mvrhel_laptop | henrys: I will try it today | 15:04.15 |
| chrisl | marcosw1: did you see my comment on Bug 696229 ? | 15:04.27 |
| marcosw1 | henrys: if you have a list of configuration options and env variables you'd like to test I can look into it. Are you just making sure they compile works or testing files? | 15:04.36 |
| mvrhel_laptop | henrys: so you did see my email about how we compare to GG on the hardware from M? | 15:05.00 |
| tor8 | jogux: okay, thanks. got a few things I need to merge and test for the desktop release before we're ready to do a release. | 15:05.14 |
| chrisl | marcosw1: I assume henrys means the env variables that gs uses at run time | 15:05.17 |
| mvrhel_laptop | we really need to figure out if we are doing something wrong as well as make sure our J files are the same as the J files that they are testing GG with | 15:05.34 |
| | I am going to try to have lunch with mq this week and talk about this all with him | 15:06.05 |
| henrys | marcosw1: I meant to ask do you want me to explain the raster ops situation to the customer? | 15:06.21 |
| marcosw1 | chrisl: yes, wasn't sure what the next step was. I suppose I need to try your commit and see if the seg fault goes away for me. | 15:06.36 |
| Robin_Watts | fredross-perry: I am almost entirely happy with the first 4 commits on robin/fred_fix. My reservations are to do with the bitmap recycling and whether it makes SUPPORT_GPROOF the default. | 15:06.58 |
| chrisl | marcosw1: that would be good - or point me at a machine I could try it on (I tried peeves without luck) | 15:07.10 |
| marcosw1 | henrys: I would appreciate it; the customers tend to push back less if it's the vp of engr. tellig them somehting can't be done. | 15:07.31 |
| Robin_Watts | The bitmap recycling has bitten us lots of times before. I'd like paulgardiner to look at that bit of the commit as he might have thoughts. | 15:07.33 |
| henrys | chrisl, marcosw1: I haven't really thought about the configuration options and env variables carefully | 15:07.40 |
| fredross-perry | Robin_Watts: ok, let me know what you decide. | 15:08.06 |
| Robin_Watts | I *believe* the android build should be smart enough to only offer the proofing button if there is a libgs.so included, in which case we are golden. I need to check that. | 15:08.29 |
| marcosw1 | chrisl: I was having trouble recreating it on any machine other than the one that I found it on. Though to be honest I didn't try very hard. | 15:08.49 |
| chrisl | marcosw1: might be nice to mention that in the bug! | 15:09.19 |
| henrys | marcosw1: will do, but I think I can explain things without my glorious title. I would think you should explain it to them and use your PhD to back it up ;-) | 15:09.26 |
| Robin_Watts | The next 2 commits are the reusable ios lib, and the iCloud support. It all looks kinda plausible, but my eyes glaze over when presented by Objective C, so someone else should review that code. Paul/Tor/Jogu all speak ObjC. | 15:09.42 |
| marcosw1 | chrisl: didn't want to discourage you :-) | 15:09.50 |
| chrisl | henrys: so where do you stand on the release - I don't mind waiting a bit longer but, as I said, I'm not convinced we'll see much more testing getting one | 15:10.14 |
| Robin_Watts | And the final whitespace fixes commit needs to pass the Tor-style police. | 15:10.20 |
| chrisl | s/one/done | 15:10.21 |
| Robin_Watts | Are you happy with my regrouping of your commits? The final result differs only in whitespace/line endings from your final result. | 15:11.19 |
| henrys | chrisl: I think rayjj and mvrhel_laptop have not given thumbs up but I assume they are good | 15:11.28 |
| | chrisl: I'm good | 15:11.36 |
| mvrhel_laptop | I am good | 15:11.52 |
| tor8 | Robin_Watts: fredross-perry: if you run the script in 'scripts/gitsetup.sh' it should set up git config and hooks to automatically flag and fix whitespace problems when committing | 15:11.57 |
| | i.e. it fixes mixed tabs/spaces and trailing whitespace | 15:12.17 |
| Robin_Watts | tor8: the whitespace fixes in the final commit are mid-line ones, mostly. See what you think. | 15:12.27 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=9da3d3a2f885fd28d6d705b53f34b545cb07cdbd | 15:12.34 |
| henrys | fredross-perry: we try to convince developers with marginal success to download and beat on the release. Please have at it each time chrisl does an rc. Thanks. | 15:12.48 |
| fredross-perry | great Iâll do that | 15:13.06 |
| Robin_Watts | There were some <TAB><space><space> things in there that I dislike. | 15:13.22 |
| tor8 | Robin_Watts: eww. vertical alignment that isn't indentation :( | 15:13.28 |
| Robin_Watts | tor8: This is why I thought I'd ask now to avoid a revert later on :) | 15:13.52 |
| tor8 | but if you're going to do any sort of vertical alignment, tabs are the way to go | 15:13.56 |
| | I'd prefer not to have them though :) | 15:14.03 |
| Robin_Watts | tor8, paulgardiner, jogux: Can one of you look over the 2 ios commits on robin/fred_fix please? | 15:14.47 |
| tor8 | it messes up if you use proportional fonts or different tab stop settings, and it makes for lots of busy-work to realign whole columns of unrelated lines when you add or remove lines there. | 15:14.55 |
| rayjj | chrisl: is today's windows 10 PDF fix in the release ? | 15:15.01 |
| tor8 | and the fallout diff noise | 15:15.09 |
| chrisl | rayjj: no | 15:15.10 |
| Robin_Watts | proportional fonts are the work of the clinically insane. | 15:15.19 |
| | people that use tab stops that aren't 8 spaces deserve all the problems they get. | 15:15.42 |
| rayjj | are we just counting on windows 10 being slow enough to roll out that it'll wait until Feb ? | 15:15.55 |
| Robin_Watts | I can't argue the other cases though, except to say that there are cases where the readability given is still a win. | 15:16.21 |
| chrisl | rayjj: I'm thinking I'll pull it in, though, given that's it's a) low risk and b) it could save us six months of repetition | 15:16.25 |
| Robin_Watts | But mixing tabs and spaces is a real no-no. | 15:16.36 |
| jogux | Robin_Watts: fredross-perry hmm. the first one that seems to mostly duplicate the entire iOS platform specific code I can't say I'd entirely fond of the duplication | 15:16.47 |
| rayjj | chrisl: that sounds better to me than having to answer the question over and over | 15:16.56 |
| tor8 | Robin_Watts: yeah. the patch, even with its Evil^TM vertical alignment, is an improvement over mixed tabs and spaces | 15:16.56 |
| chrisl | rayjj: exactly! | 15:17.09 |
| Robin_Watts | tor8: The patch *introduces* tabs and spaces :) | 15:17.14 |
| tor8 | and with Java, readability suffers enough that I'm almost inclined to believe you when you say it increases legibility :) | 15:17.18 |
| jogux | Robin_Watts: fredross-perry: the iCloud one I need to look over when I don't have my head full of SOT stuff so I can get my head around it | 15:17.32 |
| tor8 | Robin_Watts: it does? I thought it looks like it removed them... | 15:17.50 |
| fredross-perry | jogux: âthe first oneâ? | 15:18.00 |
| jogux | fredross-perry: "Initial stesp for reusable iOS library" | 15:18.26 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=shortlog;h=refs/heads/fred_fix <- 3rd commit on that. | 15:18.47 |
| fredross-perry | it is a duplicate. I just put it there for safekeeping. I can remove it. | 15:18.54 |
| | or put it in a branch. just did not want to lose it. | 15:19.10 |
| tor8 | Robin_Watts: I was looking at "Various whitespace fixes" | 15:19.16 |
| jogux | fredross-perry: yeah, I think keep that off golden for now | 15:19.27 |
| Robin_Watts | tor8: Yeah, 2 different conversations here. | 15:19.28 |
| chrisl | rayjj: there also (not for the release, just for review): http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=8f1a51009 | 15:20.08 |
| rayjj | chrisl: that commit looks good | 15:21.07 |
| chrisl | rayjj: thanks | 15:21.14 |
| rayjj | I don't have any problem doing the memset all of the time, not just when running PACIFY_VALGRIND, but it's ok the way it is | 15:22.26 |
| chrisl | rayjj: it's a potentially large block of memory, hence not wanting to do it all the time | 15:22.53 |
| | Plus, the valgrind warning if for bytes we genuinely ignore | 15:23.23 |
| | s/if/is | 15:23.34 |
| rayjj | chrisl: agreed, that it is most likely not causing any indeterminism (I hope) | 15:24.52 |
| Robin_Watts | chrisl: Looks good to me, but is it perhaps worth genuinely just setting the padding bytes? | 15:25.06 |
| | That way valgrind would still report stuff in the real bitmap area? | 15:25.30 |
| rayjj | patterns are common enough that I would expect referencing bytes that are UMR would have shown up | 15:25.40 |
| chrisl | Robin_Watts: I considered that, but it's not straight forward at that point - there's a limit to how much effort I want to put into it | 15:26.18 |
| Robin_Watts | chrisl: OK. | 15:27.08 |
| chrisl | Robin_Watts: it's because the block we allocate also contains space for the scan line pointers - if not for that, it'd be pretty trivial. | 15:28.32 |
| rayjj | can someone give me some help getting peeved DNS/IP address straightened out. peeved gets its own IP address wrong from 'host peeved.ghostscript.com' and 'dig peeved.ghostscript.com' alshas its old IP address and says: SERVER: 100.9.62.163#53 (which is peeves == ns2.ghostscript.com) | 15:33.30 |
| | so how is it that peeved is getting it wrong. Note that dig peeved.ghostscript.com on peeves (or casper == ns1.ghostscript.com) returns the correct address for peeved | 15:34.35 |
| fredross-perry | bbiab | 15:34.53 |
| Robin_Watts | rayjj: Have you restarted the dns server on peeved since you changed the config ? | 15:35.00 |
| rayjj | marcosw: I am sure that is the cause of the slowness | 15:35.10 |
| | Robin_Watts: I've restarted peeved altogether. Is there a cache somewhere that persists across restarts ? | 15:35.49 |
| Robin_Watts | rayjj: Not as far as I know. Where are you configuring it ? | 15:36.08 |
| rayjj | Robin_Watts: /etc/resolvconv/resolvconf.d has the name servers. /etc/network/interfaces has the static IP set up (but not the name 'peeved' -- that's in /etc/hosts with the correct address) | 15:40.59 |
| jogux | rayjj: which is the old and new ip ? | 15:41.32 |
| rayjj | on peeved, dig is also getting the old address for ns2.ghostscript.com from somewhere. The old address is 64.183.45.165 for peeved and 64.183.45.162 for peeves == ns2.ghostscript.com | 15:42.35 |
| jogux | so any 64.x.x.x adress is bad/old? | 15:42.52 |
| rayjj | the new (correct) address is 100.9.62.165 for peeved | 15:42.56 |
| | jogux: yes | 15:43.01 |
| jogux | so http://dns.squish.net/traverses/62cb9599293b028308511b1dd1cafa00 says that peeves.ghostscript.com is serving the wrong address then | 15:43.12 |
| | I suspect that could be because the SOA serial number wasn't changed on ns1.ghostscript.com | 15:44.13 |
| rayjj | jogux: on peeves, then it has the correct address in /etc/bind/ghostscript.com (and in master.ghostscript.com) | 15:44.27 |
| | jogux: OK. I can update that. And I assume I should do it on peeves as well ? | 15:45.20 |
| jogux | is peeves setup as a secondary (that does a zone transfer from the master) or a master (any dns has to be manually updated)? | 15:45.28 |
| rayjj | jogux: I don't remember. | 15:47.42 |
| jogux | rayjj: is there a way I can login to peeves? | 15:48.03 |
| rayjj | jogux: let me check if you have a userid there | 15:48.41 |
| | jogux: if not, I'll set one up | 15:48.56 |
| | jogux: nope, you aren't there yet. | 15:49.31 |
| | jogux: just a sec | 15:50.39 |
| | jogux: OK, you should be able to get into peeves now | 15:59.33 |
| jogux | rayjj: that works. looking :-) | 15:59.53 |
| | okay, so peeves is setup to be a slave with casper as the master. | 16:01.31 |
| rayjj | jogux: that sounds acceptable | 16:01.55 |
| jogux | so I think if you update the zone serial number in the SOA on casper and reload it's name server, that change should propogate to peeves. | 16:01.56 |
| fredross-perry | re: gitsetup.sh. Whatâs wsfix vs wsfixi ? | 16:05.06 |
| kens | OK I'm off out for dinner, goodnight all | 16:08.22 |
| rayjj | jogux: now peeves is getting a totally wrong IP for peeved ( 141.8.225.226 ) | 16:08.33 |
| jogux | rayjj: impressive. just a sec :-) | 16:08.56 |
| rayjj | jogux: OK. I restarted bind9 on peeves and it looks OK now (at least on peeves) | 16:12.20 |
| jogux | rayjj: cool. let me run that traverse again... | 16:12.59 |
| rayjj | jogux: and peeved gets the right thing from peeves now | 16:13.02 |
| | so not updating the SOA was the culprit | 16:13.25 |
| jogux | yep, traversal looks good now. | 16:13.30 |
| | rayjj: yeah, not updating it often does cause issues like this :( | 16:13.40 |
| rayjj | jogux: THANKS | 16:13.47 |
| | jogux: yeah, I do it so infrequently that I forget the magic recipe | 16:14.15 |
| jogux | rayjj: no problem :-) | 16:16.36 |
| rayjj | marcosw: that will probably resolve the slowness from peeved | 16:17.06 |
| | going to get more coffee ... | 16:21.25 |
| henrys | mvrhel_laptop: I wanted to come back to the performance stuff with you and ray when he gets back. | 16:29.29 |
| mvrhel_laptop | henrys: ok sounds good | 16:29.39 |
| henrys | mvrhel_laptop: we do have fp yes? | 16:29.46 |
| | and do we know of an asics that might be in use by the competitor? I assume your colleague would have toldy you that | 16:30.37 |
| mvrhel_laptop | fp? | 16:31.16 |
| henrys | s/asics/asic/ | 16:31.29 |
| | floating point | 16:31.33 |
| mvrhel_laptop | oh yes | 16:31.35 |
| | so we have the same dev board that they are running gg on | 16:31.58 |
| | and he said our numbers were 5 to 10 times slower for the j files. | 16:32.17 |
| henrys | mvrhel_laptop: yea but some hardware feature could be a compile switch away. | 16:32.27 |
| mvrhel_laptop | with the number we supplied to him | 16:32.27 |
| | yes | 16:32.32 |
| | he was concerned that we might have been doing some writes to disk. as gg was not doing that | 16:32.55 |
| | but I think ray said he was going to the null device | 16:33.04 |
| henrys | mvrhel_laptop: and surely he used in memory banding. | 16:33.20 |
| mvrhel_laptop | I am wondering if I could get ray's system here and take it to MQ and go over it with him | 16:33.36 |
| henrys | anyway best to wait for ray I'm going to get some coffee | 16:33.50 |
| mvrhel_laptop | yes. I will do same | 16:34.02 |
| fredross-perry | mvrhel_laptop: plz check your email regarding profiles. Thanks. | 16:35.28 |
| Robin_Watts | mvrhel_laptop: Their board is ARM based? | 16:36.05 |
| | ARMs history with FP is 'interesting'. | 16:36.54 |
| | Originally they had no FP hardware at all, and it was all done using a software emulator. They defined FP operations using the coprocessor instructions. Whenever execution hit such an instruction the coprocessor not being there caused an abort. That abort was caught in software, and the FP op was emulated in software and execution continued. | 16:38.28 |
| | Then they actually produced hardware that implemented that coprocessor, but very few chips ever shipped with that. | 16:38.59 |
| | They also did compilers that directly replaced the FP ops with calls to a software FP lib. That was 2-3 times faster than the coprocessor emulator. | 16:39.52 |
| | Then they changed the FP emulator opcodes entirely. | 16:40.08 |
| | Then they did that again. | 16:40.12 |
| | Then they came out with NEON, and changed them again. | 16:40.25 |
| mvrhel_laptop | so I do see that this part is dual core. I dont think ray was doing any multithreaded rendering he said | 16:40.50 |
| Robin_Watts | So, it's a nightmare trying to find exactly the right build options for exactly the right CPU/FP combo. | 16:41.05 |
| rayjj | henrys: back now | 16:48.05 |
| henrys | rayjj: well we'd obviously like to get to the bottom of the performance discrepancy that's easy to say... | 16:49.40 |
| | did you read above about fp and all that? | 16:50.19 |
| mvrhel_laptop | Robin_Watts and I were just chatting about this. There is some concern as to the level of fp support | 16:50.22 |
| Robin_Watts | rayjj: Do you have the toolchain you used installed anywhere ? | 16:50.28 |
| mvrhel_laptop | The spec sheet says it has "vector floating point" | 16:50.41 |
| | but Robin_Watts was concerned about some of it being software emulated | 16:50.56 |
| Robin_Watts | well, I'm concerned that the toolchain might be generating soft FP rather than using the hardware FP. | 16:51.32 |
| mvrhel_laptop | ah | 16:51.40 |
| | I see | 16:51.41 |
| Robin_Watts | The raspberry pi went through the same thing. | 16:51.56 |
| | The first versions of the distros were all doing FP in software. | 16:52.14 |
| | They got a massive speed boost when they got the FP building correct. | 16:52.30 |
| mvrhel_laptop | ok. that would be nice to figure out | 16:52.57 |
| Robin_Watts | Also, they have a NEON copro in there. | 16:56.45 |
| | NEON is for doing SIMD etc. | 16:56.52 |
| mvrhel_laptop | in the new or old part? | 16:57.19 |
| Robin_Watts | both, AIUI. | 16:57.28 |
| rayjj | Robin_Watts: OK, I have the VM up (linux) where I have the toolchain installed. What do I look for ? | 16:58.28 |
| Robin_Watts | rayjj: Urm... gcc --dump-specs? | 16:58.46 |
| | something like that. | 16:58.49 |
| | gcc -dumpspecs | 16:59.15 |
| rayjj | *cpp: | 17:02.58 |
| | %(subtarget_cpp_spec) %{msoft-float:%{mhard-float: %e-msoft-float and -mhard_float may not be used together}} | 17:02.59 |
| | Robin_Watts: does that tell us anything ? | 17:03.01 |
| mvrhel_laptop | which were we using... | 17:03.25 |
| jogux | arm gcc is fiendishly difficult to configure perfectly iirc. there's quite a few options that are "much faster but not as correct". (where not as correct may well not matter for our purposes, it's not like the results of the calcs are going into a rocket guidance system :-) ) | 17:03.27 |
| Robin_Watts | rayjj: Can you pastebin the specs file ? | 17:04.04 |
| mvrhel_laptop | its like volkswagon emissions | 17:04.08 |
| Robin_Watts | #ifdef EPA | 17:04.26 |
| mvrhel_laptop | :) | 17:04.31 |
| rayjj | Robin_Watts: jogux: the "multilib_defaults:" section has: marm mlittle-endian msoft-float mno-thumb-interwork fno-leading-underscore | 17:04.32 |
| henrys | and what's the output - 1 bit cmyk rayjj ? | 17:04.37 |
| Robin_Watts | rayjj: soft-float is bad, I am fairly sure. | 17:04.52 |
| rayjj | Robin_Watts: no, because it has the name of company M in it. I can upload it to casper or email it | 17:05.37 |
| henrys | I received a lengthy tutorial from GG folks how fast harlequin screening is at chicago I'm not sure how much of that was BS. | 17:05.41 |
| rayjj | which do you prefer? | 17:05.49 |
| Robin_Watts | rayjj: Either is fine with me. | 17:06.04 |
| mvrhel_laptop | hmm maybe we should do a NEON version of the screening SIMD stuff we have | 17:06.22 |
| henrys | mvrhel_laptop: some info about it here: http://www.globalgraphics.com/products/harlequin-screening-library/#cross-modulated we need to compete on that front also. | 17:06.28 |
| rayjj | henrys: I'd have to go back and look, but istr I was doing contone, figuring they would use the asic color correct / halftone step | 17:06.50 |
| mvrhel_laptop | henrys: oh so they have special screens | 17:07.18 |
| henrys | mvrhel_laptop: they were making a big fuss over it at chicago but you know how these things go. | 17:07.49 |
| mvrhel_laptop | my screens are supposed to do something like this | 17:07.49 |
| | yes. I don't think people get to excited about hafltone screens these days | 17:08.05 |
| rayjj | henrys: the results are attached to the email last Oct 17 (tech was cc'ed) | 17:08.09 |
| henrys | something to ask MQ how is the other rip being run? | 17:08.34 |
| mvrhel_laptop | henrys: you mean in terms of bit depth color etc | 17:08.50 |
| henrys | right | 17:09.02 |
| rayjj | henrys: I had done 600 and 1200 of CMYK contone, RGB contone, 8-bit Gray, 1-bit mono and RGB contone with BGprinting (overlapped parse/render) | 17:10.23 |
| mvrhel_laptop | rayjj: it looks like this thing has 2 arms so I am wondering if doing 2 threads makes sense | 17:11.28 |
| | once we get the fp figured out | 17:11.39 |
| rayjj | gs args were: -r600/1200 -Z: -sBandListStorage=memory -dUseFastColor=true -sDEVICE=bitrgb -dGrayValues=256 -o /dev/null -dBufferSpace=16m -dBGPrint=true | 17:11.46 |
| henrys | it has 2 arms ... ;-) sorry I can't help it, giddy today | 17:12.11 |
| rayjj | the 'bit' devices recognize /dev/null and skip the 'fwrite' step | 17:12.15 |
| mvrhel_laptop | ok well that is good | 17:12.40 |
| henrys | mvrhel_laptop: did he suspect disk access because he looked at an os trace? | 17:14.03 |
| rayjj | I had done J9, J11, J12 and the PLRM 100 page for PCL, PS and PDF | 17:14.56 |
| mvrhel_laptop | no | 17:16.17 |
| | the slow speed | 17:16.22 |
| | it was just a guess | 17:16.26 |
| rayjj | were you able to find the spreadsheet ? | 17:16.45 |
| | Robin_Watts: you can look at casper.ghostscript.com:/home/ray/public/gcc-dumpspecs | 17:18.21 |
| henrys | rayjj: was that to I'm looking at it in the email yes. | 17:19.34 |
| | s/was that to/was that to me/ | 17:19.52 |
| rayjj | henrys: OK. Glad you can still get it | 17:20.23 |
| Robin_Watts | rayjj: When you built, did you specify any particular options? | 17:21.22 |
| rayjj | mvrhel_laptop: I'll probably need a whole new toolchain. Getting that was an issue, iirc | 17:21.35 |
| Robin_Watts | Do we still have the board? | 17:21.35 |
| rayjj | Robin_Watts: yes | 17:21.41 |
| mvrhel_laptop | rayjj: apparently for the new part, they are using an open source tool chain now | 17:21.57 |
| Robin_Watts | (yes, we still have the board? Or yes, you specified options?) | 17:22.01 |
| | mvrhel_laptop: Probably the codesourcery toolchain. | 17:22.12 |
| rayjj | Robin_Watts: yes we have the board. I'll have to dig into the Makefile for options | 17:22.26 |
| Robin_Watts | rayjj: It could potentially be worth trying to set some of the options and seeing whether it makes a change to the speeds. | 17:23.04 |
| rayjj | Robin_Watts: the toolchain I used had the "eabi-hard_i686" in the path name | 17:23.39 |
| Robin_Watts | -mfpu=vfp or -mfpu=neon, and -mfloat-abi=hard | 17:23.51 |
| | Well, hopefully the i686 is the host :) The eabi-hard suggests it's properly configured though. | 17:24.30 |
| rayjj | Robin_Watts: the CC is armcc.m##x0/arm-m*******-linux-gnueabi-gcc | 17:27.02 |
| henrys | mvrhel_laptop: so I guess just asking which numbers MQ is looking at in rayjj's spreadsheet will tell us the configuration(s) he is interested in. | 17:28.50 |
| rayjj | Robin_Watts: where the ## and *** are obfuscation of the name | 17:28.58 |
| Robin_Watts | yeah, I don't learn anything new from that :( | 17:29.11 |
| | It may just be that GG have invested some time optimising their products for ARMs in a way that we haven't. | 17:29.29 |
| rayjj | henrys: yeah, we never got ANY response AFAIK as to which they might be interested in, but we should look at a configuration similar to gg | 17:29.55 |
| Robin_Watts | My experience with MQ was that he was an utter black hole. Hopefully mvrhel_laptop can get some responses out of him. | 17:30.40 |
| mvrhel_laptop | well he just lives a short distance away from here and I worked with him for about 5 years so I should be able to get something out of him. trying to meet him for lunch this week. | 17:32.15 |
| | so do we think that we are using the hardware fp then? | 17:32.53 |
| Robin_Watts | I suspect I was just never a priority for them, and he was busy with other stuff. | 17:32.54 |
| | mvrhel_laptop: I would guess that we probably were. | 17:33.04 |
| mvrhel_laptop | ok | 17:33.08 |
| | the other question is, can we get the files that they are using | 17:33.21 |
| | to test | 17:33.23 |
| | it is possible the j* files are different | 17:33.33 |
| rayjj | and we should understand which language they want. Our PCL was faster than PS on some, slower on others, but PS was a fairly in the 20 PPM for the J files and > 80 ppm for the PLRM. Hard to imagine gg being 5 to 10 times that fast | 17:33.56 |
| mvrhel_laptop | right | 17:34.05 |
| rayjj | mvrhel_laptop: in fact, I thought you said that they went from 40 to 70 ppm | 17:34.35 |
| mvrhel_laptop | who is they | 17:34.59 |
| | or what | 17:35.06 |
| | I don't recall ever giving any absolute numbers | 17:35.26 |
| | I had said the new architecture was some factor faster | 17:35.48 |
| | and that we were some factor slower than GG | 17:35.56 |
| rayjj | mvrhel_laptop: I thought it was during the phone call | 17:35.58 |
| mvrhel_laptop | no I don't have any numbers. I will try to get some | 17:36.09 |
| rayjj | but in any case I'd like to run the new board | 17:37.08 |
| mvrhel_laptop | I will print out the spread sheet and take it to lunch | 17:37.08 |
| | yes | 17:37.14 |
| | I told him we wanted that. He is going to work on getting it for us | 17:37.33 |
| rayjj | mvrhel_laptop: is that today ? | 17:37.37 |
| mvrhel_laptop | No not today | 17:37.49 |
| | either tomorrow or Friday | 17:37.57 |
| chrisl | Who did the testing these numbers come from? | 17:38.15 |
| mvrhel_laptop | he is actually on vacation this week | 17:38.16 |
| | chrisl: that is also a good question | 17:38.31 |
| | either M or GG | 17:38.36 |
| chrisl | Well, casting no aspersions on my former colleagues, but...... | 17:38.56 |
| rayjj | chrisl: you don't think gg may have fudged things ? ;-) | 17:39.04 |
| mvrhel_laptop | what would be nice is for me to go to MQs house and see GG running and get ours running on the same system | 17:39.26 |
| | and compare | 17:39.31 |
| | I may push to see about that being a possibility | 17:39.42 |
| rayjj | that'd be awesome | 17:39.47 |
| chrisl | rayjj: well, I'm wondering if some configuration tweaking may gave been done to get those specific files running optimally - ignoring real world | 17:40.14 |
| mvrhel_laptop | -dNOTRANSPARENCY | 17:40.42 |
| | for example... | 17:40.59 |
| chrisl | Transparency is one place where I feel we might be losing out | 17:41.11 |
| henrys | rayjj: it would be nice to profile this stuff and see if we have something weird going on with respect to x86 desktop profile. | 17:41.36 |
| mvrhel_laptop | yes. that whole mess could use some optimization | 17:41.38 |
| rayjj | chrisl: well, the PS and PCL versions had transparency already flattened | 17:41.51 |
| mvrhel_laptop | yes I could do some profiling too | 17:41.52 |
| | let me find out what he is focusing on | 17:42.13 |
| | before we do that though | 17:42.20 |
| chrisl | But maybe running the RIP as a server, pre-loading required fonts, optimising band size, maybe even tweaking process priorities | 17:42.22 |
| mvrhel_laptop | yes | 17:42.35 |
| | 5 to 10x slower seems so far out that that something weird has to be going on | 17:43.20 |
| chrisl | But without transparency in the mix, I'm struggling to see a 5-10x difference. You're unlikely to get that from some ARM optimisations | 17:43.41 |
| mvrhel_laptop | well the fp was a possible one | 17:44.10 |
| Robin_Watts | chrisl: Profiling on the target is the only thing we can do. There might be something REALLY stupid going on. | 17:44.18 |
| rayjj | mvrhel_laptop: and being 5 to 10 times faster than 20 ppm on the J files seems implausible given RAM bandwidth on an ARM | 17:44.34 |
| mvrhel_laptop | right. | 17:44.48 |
| | rayjj: I know it would only give us less than 2x boost but would it be worth doing 2 threads? | 17:45.31 |
| rayjj | we don't really have too much FP, particularly when running -dUSeFastColor | 17:45.35 |
| henrys | chrisl: PCL sort of rules out the PS startup time being an issue. Really like to see a profile on the arm | 17:45.49 |
| mvrhel_laptop | does the tool chain have a profiler? | 17:46.08 |
| henrys | as Robin_Watts it could be something silly | 17:46.27 |
| chrisl | henrys: it doesn't rule out process startup overhead | 17:46.34 |
| henrys | as Robin_Watts said it could be something silly | 17:46.38 |
| Robin_Watts | is frequently silly. | 17:46.59 |
| henrys | chrisl: no true but we've had a few customers complain of gs start time, that's what I was thinking about | 17:47.26 |
| | chrisl: do you know of any harlequin hardware assist for color conversion or stuff like that? | 17:48.04 |
| rayjj | henrys: that's something the board has | 17:48.19 |
| mvrhel_laptop | but we are not using it | 17:48.27 |
| | and they might be | 17:48.30 |
| henrys | that's a big deal | 17:48.44 |
| rayjj | which is why I did -dUseFastColor | 17:48.46 |
| henrys | oh maybe not such a big deal ;-( | 17:49.12 |
| chrisl | It's something I would not be surprised if they were using it - HQN were not averse to such customisations (regardless of whether it made sense) | 17:49.20 |
| mvrhel_laptop | ok. well I will find out about that as well | 17:49.44 |
| rayjj | mvrhel_laptop: that's why I mostly focused on contone configurations (except for the 1-bit mono case) figuring that the chip would be used to color correct and halftone | 17:50.36 |
| mvrhel_laptop | yes, that makes sense | 17:50.49 |
| | rayjj: are you able to profile on the arm? | 17:51.21 |
| Robin_Watts | See if the kernel has oprofile support. | 17:51.35 |
| rayjj | Robin_Watts: if I run a profile build on the target, can the host (build system) gprof make sense out of it ? | 17:51.47 |
| | Robin_Watts: how do I tell if the kernel has oprofile ? | 17:52.12 |
| Robin_Watts | rayjj: oprofile would be a better option than gprof. | 17:52.20 |
| | Do you have the opcontrol command? | 17:52.29 |
| | (he says, dredging around in the depths of his memory) | 17:52.43 |
| rayjj | Robin_Watts: I have to dig the board out of a box | 17:52.47 |
| Robin_Watts | rayjj: Ah, ok. | 17:53.08 |
| rayjj | and fire it up. That'll take a while (I'm not sure which box it's in since I moved) | 17:53.21 |
| Robin_Watts | opcontrol configures/starts/stops the profiler. | 17:53.33 |
| chrisl | oprofile can end up with information overload.... personally, I'd start with gprof | 17:53.34 |
| Robin_Watts | oprofile has never seemed too bad to me. And it's less invasive than gprof, cos it runs a normal binary. | 17:54.04 |
| chrisl | But it's full system, so gives information of everything going on - unless it's better now. | 17:54.53 |
| | And I see no reason gprof on the host wouldn't work on a profile file from the target - fairly sure I've done that before | 17:56.21 |
| Robin_Watts | chrisl: you can tell oprofile to look at a particular image only. | 17:56.38 |
| chrisl | Ah, "operf <binary>" - I don't recall that when I tried it | 17:57.30 |
| Robin_Watts | opcontrol --image=gs | 17:57.35 |
| | operf is, I suspect, a wrapper script. | 17:58.17 |
| chrisl | Probably, yes. | 17:58.25 |
| mvrhel_laptop | bbiab | 17:59.39 |
| rayjj | OK, I found the board. Now I have to remember how to hook up to it | 18:02.58 |
| | I have to run lunch to my son. bbiaw | 18:08.51 |
| mvrhel_laptop | rayjj: oh good | 18:11.29 |
| henrys | rayjj: for the logs if you have gdb this works for "silly/easy" problems on linux: for x in $(seq 1 10); do sudo gdb -ex "set pagination 0" -ex "bt" -batch -p [pid]; sleep 1; done ... there are other variations of this on the web | 18:17.16 |
| NP-Hardass | Good afternoon. Having a little trouble on windows with some PS code that I copied over from linux and would appreciate some guidance if anyone can help. I am using the font Calibri, and with the font installed properly on linux, gs loads the font when called. However, when I attempt to do so on windows, I get:https://bpaste.net/show/680b8af98996 I attempted to make a cifdmap entry, but to no avail: | 18:23.40 |
| | /Calibri << /Path (c:/windows/Fonts/Calibri.ttf) /SubfontID 0 /FileType /TrueType /CSI [(Identity) 0] >> ; (do I need some sort of flag to get it to read the cifdmap?) | 18:24.08 |
| chrisl | NP-Hardass: you need to use the "-I" command line option to tell Ghostscript where to search - point it at the directory where your customised cidfmap file is located | 18:25.50 |
| NP-Hardass | chrisl: let me give that a try | 18:26.16 |
| | chrisl: I seem to still have no luck. gswin32c.exe -DNOSAFER -I /y/gs/cidfmap input.ps output.pdf, looks correct, yes? | 18:33.31 |
| | er, no space between -I and /y/ | 18:34.06 |
| chrisl | Is the directory really called y? | 18:34.25 |
| Robin_Watts | Is /y/gs/cidfmap a directory ? | 18:34.26 |
| NP-Hardass | Robin_Watts: yes, mapped network drive mounted at Y:/ via bash so /y/ | 18:34.51 |
| | and I have the cidfmap in the cidfmap directory | 18:35.07 |
| chrisl | This isn't bash, this is ghostscript - try a windows style path | 18:35.18 |
| NP-Hardass | let me try that. | 18:35.28 |
| Robin_Watts | -IY:\\gs\\cidfmap\\ | 18:35.53 |
| chrisl | And, as Robin_Watts was getting at, you need it to point to the directory which contains cidfmap, not at the cidfmap file itself | 18:36.22 |
| Robin_Watts | otherwise bash will eat your \'s. | 18:36.31 |
| NP-Hardass | Sadly, no luck with that either. | 18:41.05 |
| chrisl | Could you try it first from the Windows command prompt? Eliminate bash as a variable | 18:42.14 |
| NP-Hardass | chrisl: Attempted that as well. | 18:43.07 |
| chrisl | Erm, the error you posted is mentioning Cambria not Calibri | 18:43.52 |
| NP-Hardass | oh, my apologies, I have the issue with both calibri and cambria, but for the sake of simplicity, I only mentioned one. I accidentally pasted the other. | 18:44.40 |
| chrisl | Well, -I<path> works on Windows for me - I just tried it | 18:46.07 |
| NP-Hardass | hmm. So must be some weird human error on my part :P Let me look over everything again. At least now I know what I *should* be doing. | 18:46.59 |
| chrisl | If the command line you posted above is what you're using, it's not going to work...... for other reasons | 18:47.35 |
| NP-Hardass | er, what did I goof otherwise? | 18:47.57 |
| chrisl | You don't specify a device and you don't (correctly) specify an output file | 18:48.07 |
| NP-Hardass | oh... Prior to switching fonts, it had been generating pdfs with that. | 18:48.53 |
| chrisl | I'd be very surprised | 18:49.30 |
| | If you don't specify a device, you'll get the Windows display device | 18:50.18 |
| | you need something like: gswin32c.exe -DNOSAFER -sDEVICE=pdfwrite -o output.pdf -Iy:\gs\cidfmap input.ps | 18:51.10 |
| NP-Hardass | Well, that I cannot explain. I have some powershell scripts that invoke-expression ghostscript and it's been generating pdfs for months :P | 19:00.29 |
| | (I do my experimentation/development in bash for simplicity) | 19:00.52 |
| chrisl | What you had above looks more like a ps2pdf command line | 19:02.17 |
| NP-Hardass | Well, for the sake of explicitness, I've switched to -sDEVICE and -o | 19:02.36 |
| chrisl | So, one thought is to move your customised cidfmap into the y:\gs directory and try it there | 19:03.30 |
| NP-Hardass | I can try that | 19:03.45 |
| chrisl | The only other thing that springs to mind is that I don't have multiple drives on my Windows box, so I can't test different drives. So maybe try it on c: instead | 19:05.08 |
| NP-Hardass | let me try that. the cidfmap, or gs itself, or both? | 19:05.44 |
| chrisl | both on the same, local drive | 19:06.07 |
| NP-Hardass | I shall give that a try. | 19:06.24 |
| | chrisl and Robin_Watts: thank you for all of your help thusfar. Much appreciated. | 19:06.53 |
| Robin_Watts | chrisl: Did you see the gs-devel thing about rc2 still failing ? | 19:07.35 |
| chrisl | I've replied | 19:08.08 |
| Robin_Watts | Were you polite? :) | 19:08.22 |
| chrisl | -ish..... | 19:08.27 |
| | NP-Hardass: well, adding a mapped network drive on my Windows box also seems to work, so.... <shrug> | 19:09.37 |
| NP-Hardass | chrisl: We'll chalk it up to human-computer interface error then :P | 19:10.03 |
| chrisl | I assume you are using a reasonably recent Ghostscript version | 19:11.48 |
| NP-Hardass | chrisl: 9.10, but I just tested 9.16 when I installed to the C drive | 19:12.33 |
| | chrisl: Well, I think at this point, I should take a break and come back to it later. I need to write some other ps documents that don't involve that font :P But really, I majorly appreciate all the help | 19:16.44 |
| chrisl | How are you loading the font? Just checking you realise the difference between fonts and CIDFonts | 19:17.27 |
| NP-Hardass | Nope, I was blindly following a stackexchange post on loading the font. | 19:18.26 |
| | chrisl: that certainly could be the problem. I'm attempting to use the ttf calibri font in windows. Beyond that, I have zero knowledge about the process. I was scraping things together from googling :P | 19:20.27 |
| chrisl | NP-Hardass: so, are you hand coding the PS? | 19:21.10 |
| NP-Hardass | yes | 19:21.19 |
| chrisl | So, are you doing something like: /Calibri findfont | 19:21.38 |
| NP-Hardass | Yessir. | 19:21.43 |
| chrisl | And not something like /Calibri-Identity-H findfont | 19:22.05 |
| NP-Hardass | correct | 19:22.12 |
| | /Calibri findfont | 19:22.22 |
| chrisl | okay, you are loading a font, not a CIDFont, so editing cidfmap isn't going to help | 19:22.39 |
| NP-Hardass | Okay, so XY problem. Rather than looking at how I attempted to resolve my issue, if I want to load the font, am using /Calibri findfont, and it doesn't find the font font with the error message indicated earlier (https://bpaste.net/show/680b8af98996), what is the best approach? | 19:24.44 |
| chrisl | Well, it depends on how you want to use Calibri - in Postcript a font can only access 255 glyphs | 19:26.01 |
| NP-Hardass | I've only been using the alphabet+punctuation. I switch to zapfdingbats to get the one special glyph I need (a black square \156) | 19:27.20 |
| rayjj | henrys: I saw your "for the logs" comment earlier, but don't know why I'd want it (setpagination 0) ??? | 19:27.24 |
| chrisl | NP-Hardass: okay, so you need a Fontmap file, rather than a cidfmap file..... | 19:27.48 |
| | NP-Hardass: in your Fontmap file, you need to include the standard mappings, which you can copy from here: http://tinyurl.com/o4odfm3 | 19:30.21 |
| | And then append the lines: | 19:30.43 |
| | /Calibri (c:\\windows\\Fonts\\Calibri.ttf) ; | 19:30.53 |
| | /Cambria (c:\\windows\\Fonts\\Cambria.ttf) ; | 19:31.22 |
| | Then use the same -I option to point Ghostscript at the directory where you've stored the Fontmap file | 19:31.56 |
| | Or, in this case, you can be more explicit, and use "-sFONTMAP=y:\gs\Fontmap" - so pointing to the *actual* Fontmap file | 19:33.14 |
| NP-Hardass | chrisl: That'll teach me to blindly google :P Let me try that out. | 19:35.24 |
| | chrisl: well, interestingly, calibri loaded, cambria did not. | 19:49.28 |
| | Progress :) | 19:49.34 |
| chrisl | That's um, odd..... | 19:50.21 |
| NP-Hardass | Indeed. | 19:51.57 |
| chrisl | Hmm, that happens for me too | 19:52.53 |
| NP-Hardass | Huzzah, a problem that isn't just mine | 19:53.04 |
| chrisl | Oh, it's because cambria is a ttc | 19:53.17 |
| NP-Hardass | Ah ha. | 19:53.33 |
| chrisl | So, change .ttf to .ttc for cambria and try that | 19:54.18 |
| NP-Hardass | So changing the extension works for cambria. How would one add the italics and bold? | 19:54.37 |
| chrisl | As far as Postscript are concerned, they are just different fonts. | 19:55.07 |
| NP-Hardass | /Cambria,Italic (C:\\Windows\\Fonts\Cambria.ttc) ; ? | 19:55.34 |
| chrisl | I'd suggest not using a command, and you need to reference the italic font file | 19:56.18 |
| | /Cambria-Italic (C:\\Windows\\Fonts\Cambriai.ttf) ; | 19:56.42 |
| | /Cambria-Bold (C:\\Windows\\Fonts\Cambriab.ttf) ; | 19:57.25 |
| | Not sure what cambriaz.ttf is..... | 19:57.51 |
| Robin_Watts | z = italic bold, IIRC. | 19:58.23 |
| chrisl | Oh, that's new.... | 19:58.41 |
| | So: /Cambria-BoldItalic (C:\\Windows\\Fonts\Cambriaz.ttf) ; | 19:59.10 |
| NP-Hardass | chrisl: My hero :) | 20:03.26 |
| chrisl | All working? | 20:03.41 |
| NP-Hardass | chrisl: Indeed. Worthy of buying you a beer. Got a donation link? | 20:03.59 |
| chrisl | No, something we're considered, but nothing came of it | 20:04.33 |
| | NP-Hardass: if you're going to be doing quite a bit of this kind of thing, I'd strongly urge at least browsing the Postscript reference manual chapters on fonts and CIDFonts | 20:05.42 |
| NP-Hardass | chrisl: well, I'm almost always logged into freenode. Ping me if/when you do. I'd like to send you one. | 20:05.54 |
| | chrisl: I shall do that. | 20:06.00 |
| chrisl | Well, if all is well, I'm going to head off - it's getting late here | 20:06.44 |
| NP-Hardass | Thank you again, chrisl | 20:08.03 |
| chrisl | No problem, glad to help | 20:08.15 |
| rayjj | well, I have the M board, but it doesn't power up (there are some lights on it). I'll have to run home and get my voltmeter and make sure that the PS is putting out the required stuff. At least I found all the docs :-) | 20:59.33 |
| marcosw1 | henrys: ping | 23:46.23 |
| | Forward 1 day (to 2015/09/30)>>> | |
IRC Logs