| | <<<Back 1 day (to 2014/08/11) | 2014/08/12 |
| tomty89 | kens: hello, do you need any help on the bug? maybe a more "distilled" file? | 08:06.42 |
| kens | tomty no, there are several problems, the first is that the code to handle LOCA format 0 tables is simply wrong. | 08:07.16 |
| | Ignore Hin-Tak, he's spouting rubbish as usual | 08:07.29 |
| tomty89 | lol | 08:07.34 |
| kens | I'e got a fix for he LOCA format 0, but now I'm running up against a different problem. THis is all to do with converting a TrueType font into a type 42 font. | 08:08.18 |
| tomty89 | speaking of convertion of font, it's interesting that if the input is an "export" from LO, gs seems to handle it very differently | 08:11.50 |
| kens | exported as a PDF you mean ? Probably the font is embedded differently | 08:12.17 |
| tomty89 | yup | 08:12.24 |
| kens | Hmm, looks like the GLYF table exceeds 64kb as well | 08:13.42 |
| tomty89 | I am not sure, doesn't look very different to me, but it seems that the the text are converted to something non-text | 08:13.48 |
| | text looks ugly in the ps and if i do ps2pdf on it, there's no font in the output | 08:14.38 |
| | but this is not the same case on the print emission from LO | 08:14.52 |
| tomty89 | is confused | 08:15.03 |
| | maybe i shouldn't bother you with too much stuff now, just let me know if you need more description/test/files from me :) | 08:16.06 |
| kens | Aha! I have text out :-) | 08:34.48 |
| tomty89 | :O | 08:36.28 |
| kens | It was another bug in the same bit of code, looks like we've never run across a format 0 LOCA table before | 08:36.52 |
| tomty89 | doesn't know what that table is | 08:37.19 |
| | some table for CJK characters? | 08:37.41 |
| kens | Its an internal table in a TrueType font, its an index basically, ti tells the parser how far along the font the start of each glyph progrm is | 08:37.51 |
| | SO when we want glyph with GID 0 we look up position 0 in the LOCA Table, and it gives us an offset, we then move to that offset and execute teh TT instructions we find tehre | 08:38.38 |
| | (simplified version ;-) | 08:38.59 |
| tomty89 | okay :P | 08:40.40 |
| kens | Essentially the problem is that a format 0 LOCA table has 16 bit (2 byte) offsets, where a format 1 table has 32 bit offsets. We were reading 32 bits forthe format 0 table as well, which meant we ran out of data | 08:41.32 |
| | Then there was an extra 'dup' (duplicate top entry on stack) in the PS program, which meant the stack was messed up. | 08:42.01 |
| tomty89 | i do notice that certain combination and length of characters triggers the problem | 08:42.28 |
| kens | Anyway, I'll fixing it and I'll run some tests | 08:42.32 |
| tomty89 | will wait patiently | 08:43.09 |
| kens | tomty89 : the fonts are subsets, so if you use more than a certain number of characters, the GLY table (whicih contains the glyph programs) will get big enough that it can't be indexed by 16-bit values. So the font embedding program shifts to 32-bit values, and the problem will go away, because *that* bit of code works fine. | 08:43.46 |
| | Which means that, probably uniquely, the LibreOffice code is actually writing a proper, minimised, subset font :-) | 08:44.40 |
| tomty89 | is suprised | 08:45.18 |
| kens | Most font embedding programs (and I shamefully include ourselves in this) just copy most of the tables in the TT font, instead of rewriting them. LibreOffice obviously does the right thing here | 08:46.13 |
| tomty89 | so it's just TOO clean lol | 08:49.37 |
| | which drive the dirty go crazy, heh | 08:49.58 |
| kens | Is it just me or has Bugzilla ceased responding ? | 09:22.56 |
| | Forget that, it finally got there | 09:23.21 |
| | tomty89 : commit 9a80562145b25a7166bd7c8e005446bd306be34e should fix this problem | 09:24.22 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=9a80562145b25a7166bd7c8e005446bd306be34e | 09:24.33 |
| tomty89 | okay, will try and report back, thanks for your effort :) | 09:55.09 |
| kens | No problem, thanks for the report :-) You'd be surprised how many people bitch without reporting a bug :-( | 09:55.39 |
| tomty89 | heh | 09:56.11 |
| paulgardiner | tor8: do you still have commits needing review? | 10:56.19 |
| tor8 | paulgardiner: there are two new reviews up :) | 11:05.03 |
| | s/review/commit/ | 11:05.24 |
| paulgardiner | tor8: okay will look | 11:07.13 |
| | tor8: LGTM | 11:12.10 |
| tor8 | paulgardiner: thanks. | 11:12.25 |
| tomty89 | kens: the patch works! though I found another another small issue of gs. you may help to confirm and look into it if you want to be kept busy. hehe | 12:45.33 |
| kens | Well I have enough to keep me busy. What's the problem ? | 12:45.52 |
| tomty89 | kens: it happens on the two emitted files i uploaded as well, seems to me the ps one would be shifted upwards when i read them | 12:47.12 |
| kens | I'm not sure exactly what you mean, can you give me a command line I can use ? | 12:47.42 |
| tomty89 | just `gs` on d00596-001 and d00597-001, compare them side by side | 12:48.19 |
| kens | Well, at screen resolutions some text is noticaebly bolder | 12:49.39 |
| tomty89 | happens to me as well but i think that maybe sort of acceptable | 12:50.01 |
| kens | That's almost certainly something which is caused by the PostScript writing from (presumably) LibreOffice | 12:50.23 |
| tomty89 | but to me, the page seems to me shifted, or in other wards, they have different margin | 12:50.33 |
| kens | Not for me (on Windows).I put the 2 display windows exactly one over the other, then alt-tab between them, the text is in exactly the same position | 12:51.09 |
| tomty89 | hmm | 12:51.18 |
| kens | Well, within a pixel or so, I can't make them overlap any more precisely that that | 12:52.10 |
| chrisl | You might be getting different default page sizes | 12:52.16 |
| kens | I w\s about to suggest that :-) | 12:52.22 |
| | The PDF file is on A4, teh PostScript file may be printed to letter, let me see | 12:53.07 |
| | Ah, it ahas a %%IncludeFeature to request A4, but it doesn't contain any code to request A4. | 12:53.47 |
| | So if your default media size is letter, theat's what you'll get | 12:54.01 |
| | Try -sPAPERSIZE=A4 | 12:54.12 |
| | Because the PostScritp file doesn't request a media size, you get whatever the default is set to. Mine is set to default to A4 :-) | 12:55.38 |
| tomty89 | oh right | 12:58.15 |
| kens | With regard to the weight of the text. If I view the PDF file with Acrobat it looks the same weight as GS. If I use Distiller to create a PDF file from the PostScript, and then view that PDF file in Acrobat, it is also heavier, again just like the GS display. Looks to me like this is a genuine difference in the way Libre Office is writing the fonts. I have no idea which one is 'correct' though. | 13:00.39 |
| | NB you get the same media size difference with teh output from Distiller too, it defaults to Letter, clearly. | 13:01.31 |
| tomty89 | i don't think I have changed the page size in LO, maybe it just doesn't write that, idk | 13:05.47 |
| | though i did just find that i have changed some font style, if it writes the pdf correctly | 13:06.11 |
| | so some text looks heavier in the ps | 13:06.19 |
| | anyway, it's LO thing now | 13:06.28 |
| kens | There's a comment in the PostScript (%%IncludeFeature), but it doens't include any actual code to alter the media..... | 13:06.28 |
| | Its not us in this case :-) | 13:06.58 |
| tomty89 | maybe LO is weaker at writing PS, heh; anyway only the printing part could emit PS, no options to export | 13:07.33 |
| kens | I would expect not, the MediaBox is written into the PDF file. There's definitely a problem with the 'Feature', but it could be the PPD (or driver) for the printer being selected when you write the4 PostScritp from LibreOffice | 13:08.48 |
| | There are also comments for the InputSlot and Duplex, again, no code to actually alter the values. | 13:09.41 |
| tomty89 | hmm that might be true, the driver seems pretty dumb to me, and LO did read something from the driver I think (like the PS Level) | 13:10.17 |
| kens | I can't really comment, all I can say is that we are doing what the PostScript program tells us to, in this case, nothing :-) | 13:10.59 |
| tomty89 | lol | 13:11.25 |
| kens | Hi robin_watts_mac in Texas now ? | 13:35.01 |
| robin_watts_mac | Yup. | 13:35.06 |
| kens | Yeehaw! | 13:35.16 |
| robin_watts_mac | 9:35 now. Seeing scott at 3:30. Going to get some kip first. | 13:35.20 |
| chrisl | How's the weather? | 13:35.27 |
| henrys | robin_watts_mac: now for the dangerous part of the journey | 13:36.01 |
| robin_watts_mac | Warm at the mo, but it's early. | 13:36.12 |
| chrisl | robin_watts_mac: give my best to Scott | 13:36.34 |
| kens | Forecast is for only 33 degrees today :-) | 13:36.54 |
| | Ohb no, sorry htat's tomorrow,28 degrees today | 13:37.27 |
| robin_watts_mac | chrisl: Happy birthday. | 13:41.42 |
| kens | O.O | 13:41.57 |
| | Also happy birthday, I didn't realise... | 13:42.13 |
| chrisl | It was yesterday - but thanks! | 13:42.22 |
| robin_watts_mac | I saw the Paul Simon quote on FB just now :) | 13:42.28 |
| henrys | chrisl: sorry day late on fb! Happy Birthday | 13:42.49 |
| chrisl | *Finally* someone gets the quote <sigh> | 13:42.51 |
| paulgardiner | Oh. Happy Birthday Chris | 13:43.23 |
| chrisl | henrys: thanks - I assumed it was a company policy thing 'cause the Artifex card arrived this morning, too ;-) | 13:43.36 |
| henrys | chrisl: oh I was thinking mid life crisis or something ;-) | 13:43.51 |
| chrisl | henrys: I don't need a mid-life crisis - my life has been in crisis since I was twelve years old...... | 13:44.27 |
| robin_watts_mac | How do people know when the middle of their life is to have a crisis? | 13:47.52 |
| chrisl | I don't think men really have a mid-life crisis - we just reach a point where our income is sufficient to act on the adolescent obsessions we never grew out of | 13:49.25 |
| pedro_mac | finds it more a case of income never beig sufficient to sustain the lifetime the wife+daughter would like to become accustomed to... | 13:50.32 |
| | lifetime->lifestyle | 13:50.56 |
| kens | nods sympathetically | 13:51.21 |
| chrisl | Probably why the "mid-life" crisis comes later for those with families | 13:51.33 |
| henrys | chrisl: being single like you with all that cash I could really have a good crisis | 13:57.43 |
| chrisl | henrys: :-) I'm just too scared to buy a motorbike....... | 13:59.18 |
| henrys | paulgardiner: if you look on my fb home page youâll find the brit cheat sheet. Now I understand you guys. | 14:05.03 |
| | I knew I was missing something | 14:05.21 |
| kens | doesn't do FB | 14:05.41 |
| henrys | http://www.tickld.com/x/30-things-british-people-say-vs-what-we-actually-mean-9-is-perfect | 14:05.49 |
| chrisl | henrys: ahem, not to worry...... | 14:06.07 |
| robin_watts_mac | I'm sure Smart Office will be fine | 14:06.24 |
| robin_watts_mac | sleeps... | 14:06.35 |
| pedro_mac | henrys: thatâs a fairly good summary :) | 14:07.46 |
| tomty89 | hmm seems some pdf makes ps2write to rasterize it | 14:08.07 |
| kens | If it contains transparency, ye. PostScript doesn't have any transparency in its graphics model | 14:08.35 |
| | You can use pdf_info.ps to see if hte PDF contains transparency. | 14:09.27 |
| paulgardiner_lap | Ha! It's so true | 14:09.39 |
| kens | Warning, some PDF file creators (hello Cairo, you know we mean you) emit transparency operations, even when the object is 100% opaque..... | 14:10.07 |
| tomty89 | aha, forbidding LO to do transparency makes that stop | 14:16.23 |
| henrys | mvrhel_laptop: I wanted to say yesterday if you wanted to come out to talk about your book with colleagues youâre welcome here. I know miles probably wouldnât cover hotel for non business. Plenty of space | 14:17.00 |
| kens | There's not much we can do about it, the only way to get the right appearance in teh PDF file is to render the transparency to an image | 14:17.01 |
| tomty89 | though "re-draw" it with `pdftocairo -pdf` first makes it stop too | 14:18.42 |
| mvrhel_laptop | henrys: ok thanks | 14:19.20 |
| kens | Anything that removes transparency will mean we don't have to render the PDF to send it to PostScript | 14:20.04 |
| tomty89 | right i got one more question about ps2write, what level/version of PS can/does it output? i saw somewhere a -dLanguageLevel option but it doesn't seems to do thing for me | 14:20.50 |
| kens | Basic level 2, no supplements. | 14:21.10 |
| henrys | we have a shrine set up here in boulder at the âMork and Mindyâ house, lots of folks are going and leaving stuff. | 14:21.20 |
| kens | The LanguageLevel switch is more or less pointless, but you can use it to get level '1.5' output. I can't see the point myself, but if you happen to have a 20 year old laser pritner lying around (and it still works), it might be needed to drive that. 1.5 is level 1 + colour extensions, tehre is no support in ps2write for language level 3. | 14:22.47 |
| | WHich is why the -dLanguageLevel=3 continues to amuse me | 14:23.19 |
| | One day I'd like a ps3write, so we oculd join the 21st century | 14:23.55 |
| chrisl | henrys: that was a huge shock - I really thought he'd got his sh*t together :-( | 14:24.00 |
| tomty89 | kens: [-dLanguageLevel=1|2|3] is in pdf2ps (sh-script) | 14:24.50 |
| kens | Maybe so, but it doesn't do anything | 14:25.13 |
| tomty89 | indeed | 14:25.26 |
| | also, heh http://www.ghostscript.com/doc/9.14/Devices.htm#PS | 14:25.33 |
| | that's why i am a bit confused | 14:25.48 |
| kens | Serves you right for reading the documentation :-P | 14:26.08 |
| henrys | why not be done with all this ps2 business pdf2ps period. | 14:26.46 |
| mvrhel_laptop | hi rayjj | 14:26.51 |
| rayjj | mvrhel_laptop: hi | 14:26.57 |
| mvrhel_laptop | I had a question for you | 14:26.57 |
| rayjj | shoot | 14:27.02 |
| kens | henrys : because people complain if I take away scripts. THe scripts were all converted instead so that they use ps2write silently :-) | 14:27.20 |
| mvrhel_laptop | how easy/hard would it be for you to run pcl monochrome 600dpi on the pi with the same files you did earlier? | 14:27.27 |
| rayjj | that's almost as bad as asking if you can ask a question ;-) | 14:27.33 |
| kens | tomty89 : from teh Overview in ps2ps2.htm "ps2ps2 is a script for converting a PDF or Language Level 3 PostScript into Postscript Language Level 2. " | 14:27.42 |
| rayjj | mvrhel_laptop: easy | 14:27.46 |
| mvrhel_laptop | ok awesome | 14:27.52 |
| | those are the numbers that company M wanted to see | 14:28.04 |
| tomty89 | kens: just about the ask that; so gs does "interprets" or "reads" PS Level 3? | 14:28.19 |
| rayjj | I can even give you an account on it so you can access it :-) | 14:28.25 |
| henrys | kens: Iâd be happy to let them complain. | 14:28.27 |
| kens | Ghostscript will handle Language Level 3 as input, yes | 14:28.35 |
| tomty89 | kens: and "rasterize" it correctly? | 14:28.45 |
| kens | tomty89 : yes | 14:28.49 |
| tomty89 | good | 14:28.52 |
| kens | henrys, I get enough bleating without that. Changing the scripts so they used ps2write and not telling anyone was a lot easier | 14:29.19 |
| henrys | kens: we could rename ps2write pswrite too the whole works | 14:29.42 |
| kens | The problem is that if people have a workflow using pswrite, or ps2write, they bitch if one of those scripts goes missing. | 14:30.14 |
| tomty89 | and maybe pdfwrite for ps2pdf :P | 14:30.16 |
| kens | To be honest, I'd just as soon delete the scripts altogether and tell people to use the damn command line | 14:30.40 |
| | Same for -dPDFSETTINGS | 14:30.49 |
| henrys | kens:bring âem on! | 14:30.53 |
| tomty89 | ALL OR NOTHING! | 14:31.09 |
| rayjj | mvrhel_laptop: 600 and 1200 monochrome 1 bit ? | 14:31.24 |
| tomty89 | ps2ps and ps2ps2 is confusing too :P | 14:31.28 |
| | actually they are almost identical | 14:31.38 |
| henrys | drinks too much coffee and goes off the rails | 14:31.39 |
| kens | THe problem is people use these things without understanding what they are doing, and then whine when it doesn't work the way they want...... | 14:31.40 |
| henrys | meeting: rayjj mvrhel_laptop : how are the board projects coming? | 14:32.31 |
| | also we have somebody miles would like to employ temporarily. He has a background in user interfaces. I thought perhaps he could try porting mvrhel_laptopâs gsview to other GUIâs. Thoughts? | 14:34.01 |
| | other ideas? | 14:34.13 |
| kens | Hmm GSView is pretty Windows focused is it not ? | 14:34.36 |
| mvrhel_laptop | henrys: yes. it is very windows focused. but someone who is good at UI's in other platforms might be able to duplicate it quickly | 14:35.10 |
| chrisl | It might be better to take Windows GSView as a template, and implement it with Qt, for better platform coverage | 14:35.42 |
| mvrhel_laptop | rayjj: they just want 600dpi monochrome | 14:35.48 |
| henrys | if we had a qt port weâd cover mac and linux. But I havenât kept up with Qt | 14:35.54 |
| chrisl | So, we'd have a Windows "port" and a Qt "port" | 14:36.01 |
| mvrhel_laptop | lets do 1 bit and 8 bit if that is OK | 14:36.02 |
| rayjj | mvrhel_laptop: thanks. 1 bit ? | 14:36.10 |
| henrys | chrisl: great minds. | 14:36.14 |
| chrisl | henrys: yeh, and us ;-) | 14:36.28 |
| rayjj | mvrhel_laptop: OK. | 14:36.31 |
| kens | The printing stuff using the XPS pipeline would be lost, that would have to be done some other way. Possibly using ps2write ? | 14:36.35 |
| paulgardiner | Aw! I've always wanted to do something with Qt | 14:36.41 |
| mvrhel_laptop | kens , cups! | 14:36.55 |
| kens | Or pdfwrite woudl probably be better thinking about it | 14:36.56 |
| henrys | paulgardiner: not in this lifetime ;-) | 14:37.00 |
| kens | mvrhel_laptop : yes that was what I was thinking | 14:37.06 |
| henrys | paulgardiner: youâre booked | 14:37.14 |
| chrisl | paulgardiner: Qt port of SOT? | 14:37.23 |
| kens | runs away screaming..... | 14:37.37 |
| mvrhel_laptop | hehe | 14:37.41 |
| paulgardiner | follows ken | 14:37.55 |
| chrisl | henrys: Qt has an impressive platform list | 14:38.04 |
| | http://qt-project.org/doc/qt-5/supported-platforms.html | 14:38.15 |
| | If *only* it wasn't C++ :-( | 14:38.28 |
| pedro_mac | we;ve done embedded Qt ports of the fileviewer before | 14:38.30 |
| mvrhel_laptop | I actually did do QT for the XPS viewer at my old employer | 14:38.36 |
| henrys | paulgardiner: originally that is what miles wanted to do with this person, my impression was that would be impossible to do independently. | 14:38.51 |
| pedro_mac | chris: plus its Qt-processed c++ | 14:38.57 |
| mvrhel_laptop | but I think if we have someone who we can hire temp for this, that would be good | 14:39.05 |
| chrisl | pedro_mac: you kind of expect that with these toolkits | 14:39.27 |
| paulgardiner | pedro_mac: In qt you can get a long way just with xml | 14:39.31 |
| henrys | paulgardiner: that said I think the next phase is probably going to be a GUI push, more at the skype meeting | 14:39.33 |
| | mvrhel_laptop: he can at least scope it out | 14:40.07 |
| pedro_mac | chrisl: yeah, its fine while it works. Not so much fun when youâre stuck debugging problems due to the moc genrerated files not quite matching your source.. | 14:40.14 |
| mvrhel_laptop | yes | 14:40.16 |
| paulgardiner | I nearly got to write an app in Qt. As part of experimenting with it, I needed to create a grid of images with the urls read from a server that specified them in xml. The whole program to do that was 43 lines of xml | 14:41.44 |
| rayjj | mvrhel_laptop: OK, timing in progress | 14:41.49 |
| mvrhel_laptop | rayjj: thank you | 14:41.57 |
| paulgardiner | henrys: skype meeting? | 14:42.14 |
| | Oh yes | 14:42.18 |
| | silly me | 14:42.22 |
| pedro_mac | paul: yeah, I did a few Qt-based apps for a customer over the last couple of years (QtDesktop plus QtQuick) | 14:42.23 |
| paulgardiner | Skype still means video to me | 14:42.31 |
| henrys | tor8:It looks like more mupdf interactive bugs are creeping in, are you able to keep up. | 14:42.35 |
| | ? | 14:42.46 |
| pedro_mac | Slightly frustrating due to the fact Digia bought it out and focussed on mobile - desktop QtQuick lagged quite a bit | 14:43.06 |
| rayjj | BTW, is anyone concerned how slow mupdf is on the Pi, even with simple things like the PLRM 100 page file ? | 14:44.23 |
| | I didn't continue testing since it was so bad | 14:45.23 |
| henrys | rayjj: I thought robin_watts_mac had gone to some trouble to speed things up - particularly on arm | 14:45.36 |
| mvrhel_laptop | rayjj: when I ran mupdf on the pi it was fast with that file. and my times were matching what Robin was seeing too | 14:45.37 |
| | rayjj: maybe I should go ahead and fire up my pi | 14:45.59 |
| rayjj | mvrhel_laptop: do you recall the times for 600 dpi cmyk ? | 14:46.21 |
| mvrhel_laptop | they are in the sheet I sent you I think rayhh | 14:46.35 |
| | rayhh | 14:46.37 |
| | rayjj | 14:46.40 |
| | can't tyep | 14:46.47 |
| rayjj | mvrhel_laptop: oops. I only looked at the first sheet :-/ | 14:46.58 |
| mvrhel_laptop | rayjj: let me double check | 14:47.42 |
| | rayjj: hmm. let me get the mupdf one | 14:48.18 |
| | apparently I did not send it | 14:48.23 |
| tor8 | henrys: I'm planning on ignoring them for a while longer :) | 14:48.25 |
| rayjj | mvrhel_laptop: I don't see anything except the gs numbers | 14:48.35 |
| mvrhel_laptop | rayjj: yes. let me send you what I had for mupdf | 14:48.54 |
| | and to tech | 14:49.03 |
| henrys | Other than that I donât have anything else: the agenda looks not so great - project progress-wise, but maybe Iâm looking at how few things Iâve ticked off my list ;-) | 14:49.34 |
| | oh 3 wingding fonts are on the way. I will use one in PCL. We should probable add one to our PS 135 collection. | 14:50.45 |
| | 4 weeks | 14:50.52 |
| | rayjj, mvrhel_laptop : please include a pointer to the test files. Drives me crazy to read a year old performance report and not have the files. | 14:51.52 |
| chrisl | henrys: remind me nearer the time (about the font) | 14:52.04 |
| henrys | chrisl: will do | 14:52.12 |
| mvrhel_laptop | Actually reading an email from Robin back on August 21st | 14:52.16 |
| pedro_mac | henrys: can we use them for SO too? | 14:52.34 |
| mvrhel_laptop | His timings with muPDF are quite fast | 14:52.48 |
| henrys | pedro_mac: yes that was the motivation | 14:52.52 |
| | for getting them | 14:53.00 |
| pedro_mac | great - thansk for sorting that out | 14:53.04 |
| jogux | henrys: awesome! | 14:57.03 |
| rayjj | mvrhel_laptop: did he include his command line ? I asked here if my command line looked reasonable, but nobody replied. | 14:57.07 |
| mvrhel_laptop | rayjj: I think we were using -m -r600 -B848 | 14:57.57 |
| | rayjj; let me get the PLRM off my pi | 14:58.12 |
| | have to dig up all the parts first though | 14:58.39 |
| henrys | rayjj, mvrhel_laptop: are we all using the same pi? Where should I get one so I can be like the big kids? | 15:00.11 |
| mvrhel_laptop | henrys: good question. | 15:00.57 |
| rayjj | henrys: I am using a Pi "B" model | 15:02.48 |
| henrys | so letâs call this meeting, please look over the workflowy agenda when you get a chance. | 15:03.34 |
| rayjj | mvrhel_laptop: If you search on the page http://ghostscript.com/irclogs/2014/08/08.html for PLRM_100 you can see my comments | 15:04.27 |
| henrys | forced skype upgrade | 15:05.08 |
| mvrhel_laptop | rayjj: ok. I am getting this thing back up and running then we might get to the bottom of this | 15:05.40 |
| rayjj | henrys: http://www.amazon.com/Raspberry-Complete-Starter-Kit-Model/dp/B00GGM0Y66/ref=pd_cp_pc_3 is a "starter kit" | 15:06.53 |
| mvrhel_laptop | btw; company M on the call shared some timing numbers for their SOCs and they showed a Pi for comparison | 15:08.13 |
| | so this is good stuff to have | 15:08.22 |
| rayjj | henrys: it has the case, which I highly recommend, the P/S (optional since phone chargers work) and the SD card pre-loaded with linux | 15:08.26 |
| henrys | rayjj: thanks Iâll get that one. | 15:09.45 |
| rayjj | henrys: that's actually a better deal than I got. My SD card was only 4Gb and I didn't get the 802.11n USB dongle or the HDMI cable | 15:10.31 |
| | mvrhel_laptop: can you email those numbers to tech (with as much info as you have on their SOC) | 15:12.16 |
| jogux | henrys: if you care, raspberry pi b+ it out now and should be the same price. main benefit is extra usb connectors (performance should be same afaik). may not matter for your intended use :) | 15:12.33 |
| rayjj | maybe you have (I haven't plowed through my mail yet) | 15:12.43 |
| | BTW, I'm running mine without the wi-fi chip (direct ethernet) | 15:13.54 |
| | mvrhel_laptop: as I reported on 08/08 mudraw -r 300 -o /dev/null -F pam -c cmyk -b 0 -B 661 -m -M PLRM_100_AR.pdf was 32 seconds per page :-( | 15:14.59 |
| | I can't try it right now since I'm getting the PCL times | 15:15.37 |
| mvrhel_laptop | rayjj: that does not sound right. I do know we were doing rgb for mupdf | 15:15.43 |
| rayjj | mvrhel_laptop: I wanted apples::apples but I tried rgb and it was only faster by 24/32 (corresponding to bits in the page) | 15:17.27 |
| | mvrhel_laptop: same thing with going to 600 or 1200 | 15:17.54 |
| mvrhel_laptop | rayjj: ok I understand | 15:18.45 |
| rayjj | so, is that command line reasonable ? And I am concerned that may the fwrites to /dev/null might be a factor -- gs detects /dev/null and skips the fwrite | 15:19.13 |
| mvrhel_laptop | rayjj: when I get my pi up I will see what I had | 15:19.35 |
| rayjj | mvrhel_laptop: OK. Thanks | 15:19.43 |
| | mvrhel_laptop: it wouldn't be in the spreadsheet, would it? (you had that in the gs spreadsheet) | 15:20.16 |
| mvrhel_laptop | rayjj: all I had was -m -r600 -B848 in the spread sheet | 15:21.50 |
| rayjj | kens2: why is http://bugs.ghostscript.com/show_bug.cgi?id=695420 minor ? If we are accessing garbage (stale memory pointer or something) it seems rather serious | 15:22.52 |
| mvrhel_laptop | rayjj: iirc though, robin_watts_mac was doing some optimizations in the end and provided the final numbers in the email that I sent you | 15:22.57 |
| rayjj | mvrhel_laptop: where does it put the output without -o /dev/null ? | 15:23.09 |
| kens2 | rayjj are we accessing garbage memory ? it seems to be simply an error message to me. | 15:23.21 |
| | No indication of a crash, nor incorrect output | 15:23.34 |
| rayjj | kens2: well, the screwy characters following ".\base\gsicc_manage.c:1050: gsicc_open_search(): Could not find " change depending on the command line used | 15:24.24 |
| | and things like 0��⺠and ?S?�⺠don't look good | 15:25.04 |
| kens2 | I imagine its the colour conversion you've specified, I don't see it as a major problem provided the output is correct and it doesn't crash. | 15:25.10 |
| rayjj | kens2: It isn't strictly the color conversion. If I do -dProcessColorModel=/DeviceeGray -dColorConversionStrategy=/Gray then there is no problem | 15:26.25 |
| kens2 | Well if you want to narrow it down so I don't have to use PDFSETTINGS to investigate, I might be more interested, but a warning in debug builds I can live with | 15:27.09 |
| rayjj | kens2: it was in a release build, not a debug build. I'll try to replicate it without the PDFSETTINGS, then | 15:28.58 |
| kens2 | I hate PDFSETTINGS because it sets many, many switches away from default settings, its well nigh impossible to figure out what is actually causing the problem. | 15:29.33 |
| rayjj | kens2: actually, it does fail with just: gswin32c -o x.pdf -sDEVICE=pdfwrite -c "<< /ProcessColorModel /DeviceGray /ColorConversionStrategy /Gray >> setdistillerparams" -f before.pdf | 15:30.05 |
| kens2 | NB I haven't *closed* the bug report, but I don;t consider this as important as a crash, or incorrect output | 15:30.05 |
| | You don't need to (and shouldn't) set ProcessColorModel when you aet COlroConversionStrategy | 15:30.33 |
| | It gets done automatically | 15:30.40 |
| rayjj | kens2: I thought that's what's in the docs. | 15:30.56 |
| rayjj | goes to check... | 15:31.02 |
| kens2 | I changed the docs | 15:31.02 |
| rayjj | kens2: " the color space chosen will be whatever the current ProcessColorModel is set to, so it is worth setting this as well, if it is important that the color space be controlled. " | 15:32.08 |
| kens2 | Well I know I changed it somewhere. Our documentation is spread around too much | 15:32.34 |
| | I stand by 'don't do that'. | 15:32.40 |
| rayjj | kens2: I'm looking at doc/ps2pdf.htm -- Maybe it only relates to LeaveColorUnchanged ??? I couldn't tell. | 15:34.02 |
| kens2 | No, it relates to all ColorConversionStrategy, you don't need to set the ProcessColorModel, it gets done by the code, and you shouldn't do it yourself. | 15:34.52 |
| mvrhel_laptop | rayjj: the only thing I had on my command line for mupdf was -m -r600 and then different sizes for -B as I was trying to determine the best size band to use. IIRC robin_watts_mac did the final testing and he did a bunch of tweeking to speed things up. | 15:36.07 |
| rayjj | kens2: without ProcessColorModel in the distillerparams, it is worse. I'll add it to the bug | 15:36.13 |
| mvrhel_laptop | rayj: also we stuck with rgb 24bit for mupdf | 15:36.23 |
| | the idea is that it could fit in the same pipeline as the scan to print | 15:36.35 |
| rayjj | mvrhel_laptop: I hope robin_watts_mac checked in his tweaks :-/ | 15:36.47 |
| mvrhel_laptop | and just leverage what ever halftone etc is going on there | 15:36.58 |
| rayjj | kens2: OK, bug updated | 15:38.38 |
| | mvrhel_laptop: OK. Once the PCL testing is done, I'll try mudraw without the "-c cmyk" But you don't know what happens without the -o ??? | 15:39.59 |
| | like, does it skip rendering to raster ? | 15:40.34 |
| mvrhel_laptop | rayjj: not sure. bbiab need to get kids out the door to camp | 15:48.27 |
| rayjj | mvrhel_laptop: I can check on my laptop -- don't bother. | 15:50.47 |
| henrys | mvrhel_laptop: so do you think the Qt port is a good idea or we can do native for each platform. | 15:58.08 |
| rayjj | henrys: native might make it tedious to make UI improvements/changes | 16:01.32 |
| henrys | rayjj: I agree, I used to actively follow Qt and knew what weâd be getting into a few years ago, not so sure now. | 16:03.00 |
| | also for mvrhel_laptop - where does he pull source from? | 16:07.36 |
| mvrhel_laptop | henrys: which source? | 16:15.16 |
| henrys | mvrhel_laptop: is the latest gsview stuff in a private repo? | 16:15.44 |
| | do you have a branch somewhere? | 16:16.05 |
| mvrhel_laptop | henrys: ok that is in the win_desktop branch of my public mupdf repos | 16:16.19 |
| rayjj | mvrhel_laptop: it looks like leaving out the -o /dev/null causes mudraw to render, but then skip the horrendously inefficient fz_output_pam_band | 16:16.24 |
| henrys | mvrhel_laptop: and the Qt question above? | 16:17.11 |
| mvrhel_laptop | rayjj: ok that sounds good | 16:17.32 |
| rayjj | that function calls fz_putc once for every component of every pixel, and that function indirectly calls file_write which does a test, then calls fwrite (with that 1 byte) | 16:17.50 |
| mvrhel_laptop | henrys: for linux and mac, I think the QT port sounds reasonable for linux and mac myself | 16:18.07 |
| henrys | thanks Iâll talk to him today | 16:18.44 |
| rayjj | mvrhel_laptop: so I'll collect mudaw timings later today and send mine around to tech | 16:19.26 |
| mvrhel_laptop | rayjj: ok sounds good | 16:19.40 |
| rayjj | the Pi has finished the 1 bit runs, it's on the 8 bit now | 16:20.11 |
| mvrhel_laptop | I need to head out for about 20 min. | 16:28.05 |
| nemo | rayjj: heh. I thought I'd go ahead and bisect for when that error appears, so I could get a usable gs... (since 9.10 just segfaulted) | 16:52.31 |
| | rayjj: I thought it happened instantly so I used one of my huge source docs | 16:52.41 |
| | but it was only triggered 307 pages in | 16:52.49 |
| | I guess I just got lucky w/ that "before" image | 16:52.56 |
| | *pdf | 16:54.55 |
| rayjj | nemo: so you get the segfault even with gs built from the current git source? | 17:10.10 |
| | nemo: and does it happen if you start with the problem page (-dFirstPage=307) ? | 17:11.05 |
| | PCL runs done for 1 bit and 8 bit. I have to reboot because my Excel is screwed up | 17:19.36 |
| nemo | rayjj: oh. hadn't. for purposes of bisect I was just going to use before.pdf | 17:19.41 |
| | but. once I'm done this, I can try that FirstPage thing, sure, why not | 17:20.27 |
| rayjj | nemo: thanks | 17:20.37 |
| nemo | I wonder if the segfault in 9.10 is related | 17:20.52 |
| | since it occurs about the same number of pages in | 17:20.58 |
| | I mean... before.pdf does *not* error in 9.10 | 17:21.14 |
| | but, you know, maybe things shifted around a bit | 17:21.28 |
| | man. git bisect is so much more annoying than mercurial bisect... | 17:23.45 |
| | ghostpdl/gs$ git bisect good | 17:23.45 |
| | You need to run this command from the toplevel of the working tree. | 17:23.45 |
| | for all git being super flexible as claimed, that is a dumb requirement | 17:24.09 |
| | who cares what my cwd is | 17:24.13 |
| | I'm doing pushd ..;git bisect good;popd now | 17:24.54 |
| | ghostpdl/gs | 17:55.50 |
| | Bisecting: 1 revision left to test after this (roughly 1 step) | 17:55.50 |
| | [161559d289a9b4306673c7d7e089182670c5090a] Slightly rejig i/o in inkcov device. | 17:55.50 |
| | ~/git/ghostpdl/gs | 17:55.54 |
| | here goes... | 17:56.09 |
| | rhuh... | 17:59.23 |
| | hm. no rayjj | 17:59.28 |
| | oh well | 17:59.31 |
| | $ git bisect bad | 17:59.32 |
| | Bisecting: 0 revisions left to test after this (roughly 0 steps) | 17:59.32 |
| | [7ef7b0d503fee02da12430ee19a394b23b1bfa6f] pdfwrite - colour conversion, consider sRGB to be RGB | 17:59.32 |
| | I don't get why that would cause http://bugs.ghostscript.com/show_bug.cgi?id=695420 | 17:59.47 |
| | but that's what it bisected down to... | 17:59.54 |
| robin_watts_mac | Yeah, skipping the output was key on he pi now you come to mention it. | 18:08.08 |
| nemo | ugh. how do I do the equivalent of hg diff -c 7ef7b0d503fee02da12430ee19a394b23b1bfa6f | 18:10.37 |
| | !@#$ git | 18:10.41 |
| | (or svn diff -c ) | 18:10.47 |
| robin_watts_mac | nemo: git diff 7efb0d5 300ee19 not work then? | 18:36.52 |
| nemo | heh | 18:46.09 |
| | yeah, that works, that's the annoying bit | 18:46.21 |
| | there appears to be no direct equiv to the other | 18:46.27 |
| | by design. | 18:46.33 |
| | inconvenient | 18:46.40 |
| | hm | 20:06.38 |
| | wish rayjj would come back so I could mention that bisect to him | 20:06.48 |
| robin_watts_mac | nemo: Ray is in California. I would expect him back today. | 20:28.41 |
| nemo | robin_watts_mac: WRT the git syntax thing, yeah, that's what I eventually did. mercurial and svn is just more convenient/intuitive | 22:47.45 |
| | robin_watts_mac: btw. git bisect, as mentioned, also pretty braindead | 22:47.55 |
| | that whole jumping to the root every time, and inability to swap good/bad | 22:48.14 |
| mvrhel_laptop | ok ran the commands that I had before with the pi. I am not matching what I had before with the PLRM. I will update to the latest gs and check that I match ray | 23:04.55 |
| | Forward 1 day (to 2014/08/13)>>> | |
IRC Logs