| | <<<Back 1 day (to 2014/01/28) | 2014/01/29 |
| Robin_Watts | I believe it works with any version of office from at least 97 upwards - possibly earlier. | 00:07.14 |
| mvrhel_laptop | Robin_Watts: ok great. that includes powerpoint, excel and word? | 00:26.03 |
| | that is rather impressive | 00:26.14 |
| Robin_Watts | I believe so. | 00:27.05 |
| mvrhel_laptop | Robin_Watts: so right now we are using the new library to convert these to pdf and then handing that to mupdf to render? | 00:27.52 |
| Robin_Watts | yes. | 00:28.07 |
| | well, it's an exe not a library technically. | 00:28.18 |
| mvrhel_laptop | ok but eventually we will rip this out to be a library with an API? | 00:28.45 |
| | and will we always be using pdf as an intermediary or something else? | 00:29.06 |
| | Robin_Watts: and right now is the other exe saving a temp pdf file that we are then reading with mupdf? | 00:30.00 |
| Robin_Watts | currently the exe loads the files and turns them into edr. This gets laid out to a "DisplayList" Then it exports the displayList to a pdf file which mupdf reads. | 00:30.47 |
| mvrhel_laptop | Robin_Watts: is edr different than a DisplayList? | 00:31.18 |
| Robin_Watts | The plan is that we should load the files into something like Edr. This Edr will get laid out into MuPDF device calls. | 00:31.50 |
| | Imagine you have a text file. | 00:32.15 |
| | If you want to be able to reflow that as the font size/page width changes, you can't use a simple displaylist. | 00:32.45 |
| | Or imagine that you have an excel file with formulas in. A simple display list won't let you do recalculations. | 00:33.24 |
| | Hence Edr is a "richer" format than a simple displaylist. | 00:33.42 |
| mvrhel_laptop | Robin_Watts: fair enough. Edr is a display list on steroids | 00:33.50 |
| Robin_Watts | yeah. | 00:34.02 |
| mvrhel_laptop | is it a standard? | 00:34.21 |
| | I guess you already told me this this morning | 00:35.29 |
| Robin_Watts | It's a picsel internal memory representation. | 00:35.33 |
| mvrhel_laptop | that is is their internal format | 00:35.39 |
| | ok | 00:35.46 |
| Robin_Watts | It's not a published standard. Doesn't even have a file format, afaik. | 00:35.58 |
| mvrhel_laptop | ok. | 00:36.06 |
| Robin_Watts | They did a streamable displaylist format too, called efif, that was used for very thin clients. | 00:36.31 |
| mvrhel_laptop | so the longer term plan as you say would be to map this format to fitz calls | 00:36.40 |
| Robin_Watts | Yeah. | 00:36.48 |
| mvrhel_laptop | and you will have that wrapped up in a couple weeks if I know you ;) | 00:37.07 |
| Robin_Watts | although, if we want editability, we might need to have some sort of edr equivalent. | 00:37.25 |
| mvrhel_laptop | right | 00:37.32 |
| Robin_Watts | or possibly several such edr equivalents. | 00:37.35 |
| | mvrhel_laptop: I don't think this is a couple of weeks work :) | 00:37.50 |
| mvrhel_laptop | even for you? | 00:37.55 |
| Robin_Watts | I started something with mupdf that I thought would be a quick change on friday, and the rabbit hole keeps getting deeper. | 00:38.30 |
| | I'm a bad judge of how long things will take. | 00:38.42 |
| mvrhel_laptop | me too | 00:40.38 |
| | Robin_Watts: ok thanks for all then information | 00:40.48 |
| Robin_Watts | np. | 00:40.53 |
| mvrhel_laptop | s/then/the | 00:40.54 |
| | bbiaw | 00:41.00 |
| henrys | Robin_Watts:this would probably be a mess but tagged pdf gets us layout, javascript we can recalculate could we create as powerful a display list as EDR using pdf? | 00:51.04 |
| ray_laptop | Robin_Watts: sounds like what I went through moving space_params to the gx_device struct (from the printer device) | 01:37.38 |
| kens | Back in a few hours. How did squash work our chrisl ? | 10:22.08 |
| chrisl | Also back in a few hours | 10:22.50 |
| Nickopoll | Hello. The interpreter does not find the font Courier. Receive unreadable text output (txtwrite). How to fix it? | 10:47.58 |
| Robin_Watts | Nickopoll: Hang around for a few hours. the people who can answer that have just stepped out. | 10:50.43 |
| | tor8: I've just about got MuPDF back to working form again with my changes in. | 11:51.20 |
| | I've got a couple of files giving grief, but broadly it's there. | 11:51.41 |
| | I've pushed the changes to robin/master. | 11:51.48 |
| | See what you think when you have a mo. | 11:51.54 |
| | I'm going to do some lcms and GhostDocs stuff for a bit cos I need a break from it. | 11:52.11 |
| | no hurry. | 11:52.37 |
| | who broke pcsfont.c then? | 12:46.31 |
| kens | What's pcsfont.c ? | 13:04.54 |
| | Pretty sure it wasn't me.... | 13:05.08 |
| Robin_Watts | part of pcl. | 13:05.21 |
| | it's broken in DEBUG builds other than for gcc. | 13:05.34 |
| | Simple fix. | 13:05.38 |
| kens | OK glad its simple at least | 13:05.48 |
| pilaar | Hi all | 13:25.03 |
| | I use ghostscript to convert postscript to pdf but have an issue with the created pdf | 13:25.18 |
| | Images are only rendered correctly on acrobat reader on windows | 13:25.33 |
| | other combinations show black bars on top of images | 13:25.41 |
| | anyone any idea what could be wrong? | 13:25.53 |
| kens | What other readers ? IKf Acrobat displays it correctly the chances are its correct. | 13:29.35 |
| | Also we would almost certainly need to see an example, and what verison of Ghostscript are you using ? | 13:30.09 |
| pilaar | I'm using ghostscript 9.10 | 13:31.50 |
| kens | Have you tried opening the PDF files with that version of Ghostscript ? | 13:32.05 |
| pilaar | Acrobat reader on mac has the same issue | 13:32.12 |
| | and the native pdf viewers of firefox and chrome as well | 13:32.23 |
| | pdf.js for example | 13:32.26 |
| | will try to upload an example pdf if that could help | 13:32.36 |
| kens | THe native Javascript viewers don't render transparency correcxlty, amongst many other things | 13:32.45 |
| | They are not a good reference. | 13:32.59 |
| | You can open a bug report if you prefer, don't forget to attach the original PostScript and supply the command line you are using | 13:33.23 |
| pilaar | OSX preview doesn't either? | 13:33.24 |
| | ok, will do so | 13:33.35 |
| kens | Acrobat Reader is not the same as OS/X preview.... | 13:33.58 |
| pilaar | i know | 13:34.05 |
| | I mean not Acrobat nor OS/X preview render the pdf correctly | 13:34.18 |
| kens | Well, I can't venture any guesses without seeing the source, and possibly not even then | 13:34.43 |
| | source PostScript that is. | 13:35.01 |
| pilaar | I understand | 13:35.56 |
| | WIll create a bug report and add both ps and pdf | 13:36.10 |
| | thanks for the reply in any case | 13:36.16 |
| kens | No problem | 13:36.22 |
| | Nickopoll_ : it seems like your Ghostscript is improperly installed if it can't find Courier. However that should not affect txtwrite. In order to answer your question we would need to see your source file. Not all of what appears to be text in a PDF file is actually text, and not all of that can be succsefully reconstructed into an editable fomr without OCR software. | 13:42.40 |
| chrisl | kens: the weekend was good, thanks - my squash, however, was middling - I lost two matches, and won two matches, finished 10th out of 16 in my grade..... I really should have travelled down on Friday, rather than Saturday morning. | 13:47.29 |
| kens | Hmm I guess so, being ill can't have helped either | 13:47.46 |
| chrisl | No, I felt really rough on Saturday morning, to the point I very nearly bailed.... | 13:48.50 |
| kens | Hmm i7 seems to be stuck or unreasonably slow. Its still 'building ghostXPS' when the other nodes have processed hundreds of jobs | 13:49.11 |
| | Oh its just very slow | 13:49.23 |
| Nickopoll_ | kens: I found that the problem is not in the font... | 13:52.48 |
| | I get the text in abnormal encoding on output. | 13:52.53 |
| | Like this "âÐÑÐЮÑÐжâТÑÐаÑÐЬÑÐЪâÐÑÐФ âÐÑÐâ£âÐÑÐЩÑÐжÑÐаÑÐЬ:" | 13:53.01 |
| kens | Nickopoll_ : that can be the case, depends on what's in the input. | 13:53.16 |
| Robin_Watts | kens: possibly it's runnning overnight jobs etc. | 13:53.18 |
| kens | Robin_Watts : never thought of that.... | 13:53.27 |
| Nickopoll_ | in the input just russian text | 13:53.56 |
| kens | Nickopoll_ : if the input has no ToUnicode info, the font is not ecndoded in some standard format, and the glyphs are not named with standard names, we run out of options. | 13:54.03 |
| | Nickopoll_ : if its RUssion and there is no TOUnicode information then there is no possible fallback, so the text is emitted 'as is' in the hope that it is comprehensible | 13:54.42 |
| norbertj | Hello Chrisl | 14:24.16 |
| chrisl | norbertj: Hi | 14:24.24 |
| norbertj | I have a question on ufst6.3, I noticed that some of the agfanames in plftable.h have been changed. A.o. UniversMT-Medium to Univers-Medium | 14:25.06 |
| | What I see is that they have different metrics. Do you know why the afganames have been changed? | 14:25.35 |
| chrisl | No, I don't think I changed those - let me have a look in the logs..... | 14:26.02 |
| norbertj | I checked UniversMT-Medium against the LJ4100 and they have same metrics. | 14:26.23 |
| chrisl | norbertj: It looks like it was me that changed it, but I'll need to dig through some old branches to find out why :-( | 14:32.00 |
| norbertj | It must have been before 8.71. I only just noticed, because we had a replacement for plftable.c (re-ordered the typefaces in the resident-table to match our legacy printeroutput). | 14:32.12 |
| chrisl | Hmm, the commit I was looking at was between 9.08 and 9.10..... | 14:32.53 |
| norbertj | It's even before 1.52 That's as far as I can go back ;) | 14:37.56 |
| henrys | Robin_Watts: did you say I broke the pcl build? | 14:40.52 |
| chrisl | norbertj: I really have no idea - it seems to predate teh history I have immediately available - maybe henrys can recall? | 14:42.14 |
| Robin_Watts | henrys: yeah, msvc debug builds at least. Trivial fix though, which has gone in. | 14:42.50 |
| chrisl | henrys: the change from UniversMT-Medium to Univers-Medium for the UFST font list in plftable.h - any ideas? | 14:42.57 |
| | norbertj: it's possible it's related to to which HP model(s) we're emulating.... | 14:43.37 |
| norbertj | chrisl, henrys: yes in FCO2 (UFST4.x) it's called Univers-Medium, in FCO3 (UFST5.0) it's called UniversMT-Medium, and in UFST6.3 it seems to be called Univers ( U001-Reg) | 14:44.33 |
| henrys | norbertj: I do remember fiddling with the names when fco's changed. | 14:45.28 |
| norbertj | when I switched from UFST4.7 to UFST5.0 I found that some of the names were changed.. And in UFST6.3 I see that the UniversMedium is not present (but there is a Univers) | 14:45.51 |
| chrisl | norbertj: really? There are metrics for Univers-Medium..... | 14:46.38 |
| norbertj | chrisl, so I think I just have to check for the correct agfaname. The metrics for UniversMT-Medium is different from Univers (both are REGULAR, NOBOLD, 4148) | 14:48.07 |
| | chrisl: If I print your ghostpdl-9.10-ufst-fixes. It looks ok though. So I'll doublecheck my code. | 14:50.53 |
| chrisl | norbertj: The font metrics that ship with 6.3 include metrics for Univers-Medium, so I would expect that font name to exist in the FCO, too | 14:52.34 |
| henrys | heading out be back in a few hours. | 14:56.40 |
| norbertj | I stepped through the pl_load_built_in_mtype_fonts, and indeed there is a Univers-Medium. | 15:00.21 |
| ray_laptop | morning, all | 15:08.27 |
| chrisl | hi ray_laptop | 15:08.36 |
| ray_laptop | Finally, I have a clean regression run after moving the space_params to the gx_device struct.! Whew!! I also got rid of the extra 'page_uses_transparency' in space_params (there was another in the device) | 15:10.34 |
| | now I need a volunteer to look over my changes. I kept the original fix for bug 689805 as a separate commit, then the commit to move the space_params to gx_device | 15:14.30 |
| | I have pushed those two commits to my repo on http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=summary | 15:22.11 |
| | Next, I'll look at all of the 'duplicate' bugs to make sure they're OK. But at least "Dryer.pdf" works fine, and completes in only 42Mb | 15:24.13 |
| kens | Sounds great news Ray | 15:27.20 |
| ray_laptop | That file needed 1.5Gb before the clist accumulation of pdf14 transparency | 15:27.29 |
| kens | *massive* improvement | 15:27.50 |
| ray_laptop | Now it does run a bit more slowly. With (old) page mode it took 47 sec. With the clist accum it takes 78 sec | 15:31.24 |
| | ("a bit!" he exclaims) | 15:31.50 |
| kens | Yeah, but it runs.... | 15:32.35 |
| Robin_Watts | mvrhel_laptop: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=cdae1c9f93bda0b8c45ecc3d59df066fbff74aed | 15:32.42 |
| kens | previously it would often error out on VM | 15:32.45 |
| Robin_Watts | mvrhel_laptop: That's the import of the new lcms, and the required locking functions for it. | 15:33.12 |
| | I haven't fiddled with any threading stuff though. | 15:33.40 |
| | paulgardiner: I've merged our two epage.git's and pushed the results to mine. | 15:40.42 |
| paulgardiner | Robin_Watts: looks good: empty diff between that and my local master so it's equivalent to what I last built from | 15:54.16 |
| Robin_Watts | paulgardiner: Is it? | 15:55.37 |
| | Rats. | 15:55.39 |
| paulgardiner | Is that a problem? | 15:55.54 |
| Robin_Watts | I think I lost some tool tweaks then :( | 15:55.55 |
| paulgardiner | :-( Locally I'd rebased over your updated version | 15:56.29 |
| Robin_Watts | oh, so maybe you have the updated version locally. | 15:56.51 |
| paulgardiner | I certainly had some of your tool tweaks | 15:57.12 |
| | I no longer needed to special case 64bit | 15:57.32 |
| Robin_Watts | yeah, my tweaks look to be there. | 15:57.39 |
| ray_laptop | Robin_Watts: so will this lcms allow us to share link profiles across threads ? | 15:57.41 |
| Robin_Watts | the 64bit was the one I was hoping for. | 15:57.49 |
| | ray_laptop: potentially yes. | 15:57.54 |
| | that was the hope. | 15:57.58 |
| ray_laptop | Robin_Watts: Great! Be interesting to see if it helps NumRenderingThreads>1 | 15:58.33 |
| Robin_Watts | indeed. | 16:01.22 |
| ray_laptop | all right. All of the "duplicates" of Bug 689805 work now! | 16:03.59 |
| | one last bmpcmp run... | 16:04.44 |
| mvrhel_laptop | Robin_Watts: ok thanks. I have to get a couple things done for miles. I may not get to look at this until tomorrow | 16:46.16 |
| | Robin_Watts: I will unleash the ifdef of the cms being threadsafe and see what happens | 16:47.32 |
| | kens: the email you forwarded me on the output intent profile | 16:48.37 |
| kens | yes Michael ? | 16:48.44 |
| | that's all teh information I have | 16:48.51 |
| Robin_Watts | mvrhel_laptop: No hurry whatsoever. | 16:49.00 |
| mvrhel_laptop | I wonder if the output intent profile is actually in the file, or just the name | 16:49.03 |
| | if it is the name (as a standard name), then we don't handle that | 16:49.17 |
| Robin_Watts | Actually, I've just thought of something wrong with that commit. Let me update it now. | 16:49.19 |
| kens | mvrhel_laptop : no idea, but I would think the profile needs to be there for PDF/X3 | 16:49.24 |
| mvrhel_laptop | kens: with output intents you can actually just have the name of the profile and where one might find it | 16:49.53 |
| | not sure though if that is the case with PDF/X3 | 16:50.05 |
| | you are probably right in that case | 16:50.10 |
| | it would be good to get the file | 16:50.16 |
| | I will reply to him | 16:50.21 |
| Robin_Watts | mvrhel_laptop: updated. | 16:50.23 |
| kens | You cna sk him for it | 16:50.23 |
| mvrhel_laptop | Robin_Watts: what is updated? | 16:50.41 |
| kens | mvrhel_laptop: or if you aren't on gs-devel I can ask for the file | 16:51.35 |
| | looks like he opened a bug | 16:51.52 |
| | with a file | 16:51.57 |
| mvrhel_laptop | Oh even better. | 16:52.31 |
| | I will have a look at that later this week | 16:52.43 |
| Robin_Watts | mvrhel_laptop: I just remembered that my optimised cached transform stuff will break in the multithreaded case. | 16:53.19 |
| | so I nobbled that. | 16:53.23 |
| mvrhel_laptop | ah ok | 16:53.27 |
| Robin_Watts | It doesn't really cost us anything; I just don't copy the latest version back to the cache at the end of a buffer conversion | 16:53.44 |
| mvrhel_laptop | kens: what bug number is it? | 16:53.55 |
| kens | 694982 | 16:54.19 |
| | assigfned to you | 16:54.26 |
| | actually maybe its someone elese | 16:54.53 |
| mvrhel_laptop | that is a different bug | 16:55.01 |
| kens | yeah it looked similar at first glance | 16:55.11 |
| | give me a minute and I'll send hmi a reply | 16:55.25 |
| mvrhel_laptop | ok thanks | 16:55.28 |
| kens | I suggested he opens a bug report | 16:59.27 |
| ray_laptop | so the work to use a clist for pdf14 rendering to non-clist devices showed up 3 bugs. Two where clist mode gets it wrong, one where page mode gets it wrong. I opened bugs for all three. | 17:01.40 |
| | Robin_Watts: mvrhel_laptop: One of you is probably best to look over my patches. | 17:02.02 |
| mvrhel_laptop | ray_laptop: ok | 17:02.22 |
| ray_laptop | Robin_Watts: mvrhel_laptop: Also, do you think I should squash these to a single commit before pushing to master ? Without the second commit, the results are the same, but -dBufferSpace=___ doesn't work. | 17:03.11 |
| mvrhel_laptop | finally we are getting some snow in our mountains | 17:06.10 |
| ray_laptop | sure will be nice to have the oldest customer bug on the list finally be closed :-) | 17:06.17 |
| Robin_Watts | ray_laptop: could be. Looking now. | 17:09.06 |
| ray_laptop | mvrhel_laptop: I saw they are forecasting snow for Tahoe and Mammoth as well. Mammoth is "only" 6 hours away. No snow (except man-made) locally in the 10 day forecast :-( | 17:12.34 |
| mvrhel_laptop | henrys: did we get the ATS files for Office from QL? | 17:19.06 |
| Robin_Watts | 450Gig of testdocs files have arrived so far... | 17:21.20 |
| mvrhel_laptop | Robin_Watts: ok. do know of any docs that would be good for demo? ones that dont have any issues? if not, I can start working on something | 17:22.39 |
| Robin_Watts | mvrhel_laptop: No, not offhand. | 17:24.07 |
| | The files are on peeved in /home/testdocs/testdocs/ | 17:24.34 |
| mvrhel_laptop | ok thanks | 17:25.06 |
| Robin_Watts | ole/msword contains the .doc files. | 17:25.53 |
| | oh, wait... | 17:26.25 |
| | yeah, those ones. | 17:27.51 |
| | ray_laptop: I'm guessing you don't want the gsmalloc.c changes in the first commit. | 17:30.13 |
| mvrhel_laptop | darn mupdf app crashes when I try to open one of my test docs | 17:31.51 |
| Robin_Watts | ah, I see the gsmalloc.c changes got removed in the second commit. | 17:33.36 |
| | That seems a good reason for squashing the two together to me :) | 17:33.47 |
| mvrhel_laptop | the Android QuickOffice app opens it :( | 17:35.17 |
| Robin_Watts | mvrhel_laptop: rats. | 17:35.45 |
| mvrhel_laptop | but it does get some of the stuff wrong at least | 17:35.58 |
| Robin_Watts | ray_laptop: You used to have: code = gs_cspace_indexed_lookup_bytes | 17:36.11 |
| | and you've replaced that with the same thing without the code = | 17:36.23 |
| | presumably because code is never checked. | 17:36.55 |
| kens | Goodnight folks | 17:37.06 |
| Robin_Watts | Would be better (IMHO) to use (void)gs_cspace_indexed_lookup_bytes | 17:37.12 |
| | cos that implies that you know that you are ignoring a return code. | 17:37.25 |
| | would be even better to act on the return code :) | 17:37.59 |
| | ray_laptop: OK, I've read through both patches. I can say that I only understand a fraction of it, but that's more than I want to have to understand :) | 17:39.10 |
| ray_laptop | Robin_Watts: can't say as I blame you. So at least you didn't see any glaring typos. | 17:41.06 |
| | Robin_Watts: what do you think about squashing the two together ? | 17:41.23 |
| Robin_Watts | only what I mentioned above. | 17:41.42 |
| | and yes, I think you should squash to two together, if only to get rid of the gsmalloc.c changes. | 17:41.57 |
| ray_laptop | Robin_Watts: oops. I didn't read far enough back. I'll have a look. | 17:42.05 |
| | I use it so infrequently, I've forgotten the magic git command to let me interactively squash | 17:46.49 |
| Robin_Watts | git rebase -i HEAD~10 | 17:47.56 |
| | I use that all day long to massage my histories into something approaching coherency :) | 17:48.44 |
| mvrhel_laptop | Robin_Watts: quick question for you | 17:49.37 |
| ray_laptop | Robin_Watts: thanks. I didn't think I wanted git merge --squash ... | 17:50.20 |
| mvrhel_laptop | so the differences that I see with respect to page breaks and where information is placed on which page. is that a function of some media page setting in the MuPDF? Maybe things are set for A4 in the Word to PDF process? | 17:51.42 |
| | excuse in media settings in the Word to PDF not mupdf | 17:52.08 |
| | s/in/me/ | 17:52.13 |
| | can't type | 17:52.14 |
| Robin_Watts | mvrhel_laptop: I don't know. Could be. | 17:52.37 |
| | I would have thought that the page sizes were set in the word files themselves. | 17:52.58 |
| | It's possible that the fonts used by epage and office don't match? | 17:53.21 |
| mvrhel_laptop | me too. | 17:53.28 |
| | I am just trying to understand why the different | 17:53.36 |
| | oh that could be | 17:53.42 |
| Robin_Watts | I'm trying to simplify our converter app at the moment. | 17:54.02 |
| mvrhel_laptop | Robin_Watts: yes, that is likely the case | 17:54.09 |
| Robin_Watts | Hopefully as I do that it will become clear if it needs to init the font library or not. | 17:54.19 |
| mvrhel_laptop | there is clearly a different | 17:54.22 |
| | difference | 17:54.24 |
| Robin_Watts | If it does then maybe we can put the standard fonts in there? | 17:54.43 |
| mvrhel_laptop | Robin_Watts: is there a way to save as PDF from the Android app given that we have PDF as an intermediate form | 18:29.36 |
| Robin_Watts | mvrhel_laptop: How would we save an xps file as a pdf file? | 18:29.57 |
| mvrhel_laptop | I don't want to do xps | 18:30.05 |
| | only the office stuff | 18:30.09 |
| Robin_Watts | Currently, no. | 18:30.24 |
| mvrhel_laptop | actually it was Miles who asked about it | 18:30.30 |
| | ok | 18:30.34 |
| Robin_Watts | I can give you an exe to take office -> pdf if you want. | 18:30.51 |
| mvrhel_laptop | no that is ok | 18:31.09 |
| Robin_Watts | but the whole office -> pdf is just a cunning idea of henrys to get us up and running. | 18:31.34 |
| mvrhel_laptop | I understand | 18:31.42 |
| | but having a save as PDF option when we have opened an office file would be nice for demo | 18:32.14 |
| Robin_Watts | mvrhel_laptop: I understand. That's one for paulgardiner though... | 18:32.47 |
| mvrhel_laptop | yes | 18:32.50 |
| ray_laptop | mvrhel_laptop: I assume you are too wrapped up in other things to look over the patches, so I'll push them based on Robin's suggestions (as a single commit) and clean up any problems afterward. | 18:36.52 |
| mvrhel_laptop | ray_laptop: yes. I am sorry. I can't get to them until tomorrow at the earliest | 18:37.22 |
| ray_laptop | mvrhel_laptop: NP | 18:37.28 |
| | I am just eager to close that bug :-) | 18:37.41 |
| | Robin_Watts: mvrhel_laptop: BTW, I did add a statement about using the clist to for PDF 1.4 transparency to the Use.htm -- I had forgotten that previously. At least that won't cause a compile fail :-) | 18:38.50 |
| JakeSays | hey does mupdf support printing? | 18:38.56 |
| Robin_Watts | JakeSays: In a limited form, yes. | 18:39.10 |
| | in that we have code to go to pcl or PWG. | 18:39.29 |
| ray_laptop | it's really up to the app to send it to the printer. | 18:39.49 |
| jo0nas | mvrhel_laptop: you wrote yesterday that you "don't see why ETS would not be GPL" - can you elaborate on that, or do you perhaps need elaboration on my part? | 18:39.53 |
| JakeSays | hmm. ok thanks | 18:40.03 |
| Robin_Watts | joOnas: ETS is a patented technology. | 18:40.15 |
| jo0nas | patents != licensing | 18:40.25 |
| Robin_Watts | so presumably we'd need some sort of patent release in there. | 18:40.33 |
| jo0nas | what does "patent release" mean? | 18:40.47 |
| Robin_Watts | jo0nas: as you were told yesterday by henrys, it probably requires some work on our end. | 18:41.03 |
| ray_laptop | jo0nas: right. Robin_Watts in the GS LICENSE we already have the verbage for those patents | 18:41.23 |
| jo0nas | oh, because Ghostscript as a whole is now AGPL 3, which involves anti-patent clauses? | 18:41.49 |
| Robin_Watts | I mean that if we released a bunch of code under the GPL that relies on a patented technique, people could still not use that code unless they had a patent license. | 18:42.05 |
| JakeSays | Robin_Watts: actually that may be enough - if mupdf generated the pcl for a page, then i should be able to just copy that to the printer port | 18:42.34 |
| Robin_Watts | I don't believe AGPL has any anti-patent stuff in it offhand. | 18:42.41 |
| | at least, none that applies to us. | 18:43.01 |
| jo0nas | you as project could make enabling that code optional, and users could decide if the patent were relevant for their jurisdiction | 18:43.02 |
| Robin_Watts | jo0nas: We could. | 18:43.13 |
| jo0nas | you could have it disabled by default, I mean | 18:43.19 |
| Robin_Watts | And I think that would fall under the "requires some work on our end" statement. | 18:43.30 |
| ray_laptop | No, it doesn't. The only "gotcha" is Raph's statement in LICENSE that says: Inventor reserves all other rights, including without limitation, licensing for software not distributed under the GNU Affero General Public License. | 18:43.38 |
| jo0nas | patents do not disallow revealing the source, I believe | 18:43.39 |
| Robin_Watts | jo0nas: Of course they don't. | 18:43.56 |
| | The whole deal with patents is that they tell you how the magic trick is done, on condition you don't do the trick yourself without a patent license. | 18:44.24 |
| ray_laptop | jo0nas: not at all. In fact, the patent is _supposed_ to teach one how to duplicate the invention (not that they ever do, once a lawyer gets done with it) | 18:44.31 |
| jo0nas | right now you include ETS - I don't follow how it would require _more_ work to disable by default than to rip out the code entirely | 18:44.43 |
| | my point is, I don't follow why an argument is raised that it "requires some work on our end" | 18:45.17 |
| mackross | Hey all, just wondering if anyone has seen a segmentation fault crash when processing large PDFs? | 18:45.47 |
| jo0nas | "some work" compared to "some other work" it seems to me - not "some work" compared to "no work" | 18:45.51 |
| ray_laptop | and I can't tell you the number of times I've tried to duplicate some invention using what is patented, only to discover it was totally bogus, and the examples included needed other "tricks" not described in the patent. | 18:46.00 |
| | mackross: which product ? | 18:46.17 |
| Robin_Watts | jo0nas: I don't understand your problem here. You've identified that the licensing for a section of code needs clarification. We've agreed that it needs clarification. That requires us to do some work. | 18:46.40 |
| mackross | ghostscript 9.10 running on heroku (Ubuntu 10 64bit) | 18:46.44 |
| jo0nas | Robin_Watts: tight | 18:46.58 |
| | whoops - s/tight/right/ :-) | 18:47.08 |
| ray_laptop | mackross: there have been a couple of segfaults fixed since 9.10 was released, yes | 18:47.12 |
| Robin_Watts | so, your choices are to strip that bit out in your distro, or to wait for us to do the work. | 18:47.36 |
| jo0nas | right (have already done that first option) | 18:47.54 |
| ray_laptop | mackross: first, get the latest (from git.ghostscript.com), build it and try that with your file. If that still segfaults, then please open a bug on bugs.ghostscript.com | 18:48.11 |
| mackross | Ah nice. What's the best way to get the updated source? | 18:48.14 |
| | awesome | 18:48.18 |
| jo0nas | ...or, have already stripped the code, but not yet tested what damage is done by that | 18:48.27 |
| mackross | read my mind. thanks ray_laptop! | 18:48.28 |
| Robin_Watts | jo0nas: What bit did you strip out ? | 18:49.33 |
| ray_laptop | mackross: eg. from http://git.ghostscript.com/?p=ghostpdl.git;a=summary get the "snapshot" tar.gz file from my commit 12 min ago | 18:49.35 |
| henrys | mvrhel_laptop: I don't understand this eta should be dual license like everything else. | 18:49.38 |
| | mvrhel_laptop: paragraph 1 removed. | 18:49.51 |
| | s/eta/ets | 18:50.04 |
| jo0nas | Robin_Watts: toolbin/halftone/ETS/* | 18:50.06 |
| Robin_Watts | jo0nas: AIUI that will have no effect on the operation of gs at all. | 18:50.31 |
| jo0nas | sounds excellent :-) | 18:50.43 |
| ray_laptop | henrys: note that the precursor to Robin_Watts' and mvrhel_laptop's (massive) improvements have always been in the "rinkj" directory and have been part of the GPL gs for YEARS | 18:51.15 |
| Robin_Watts | Frankly ETS should probably be in a separate repo rather than being in there. | 18:51.35 |
| ray_laptop | Robin_Watts: I agree, since we license it separately | 18:51.59 |
| henrys | ray_laptop: I'm sorry I missed most of this but we do want ETS in the open source ghostscript release, and if the only thing we need to do is change the paragraph let's do it. | 18:52.49 |
| Robin_Watts | henrys: Why do we want it in the gs release? | 18:53.12 |
| henrys | Robin_Watts: why would we want to do the work of an extra release for it? | 18:53.45 |
| jo0nas | another issue (experienced with 9.07): Ghostscript fails if a PDF references an unknown font and there's WOFF files in fontconfig path - see https://bugs.debian.org/732440 | 18:53.53 |
| Robin_Watts | gs doesn't use it. (at least not the version in gs/toolbin/halftone) | 18:53.55 |
| jo0nas | is that issue known to you - and perhaps even fixed by now? | 18:54.20 |
| Robin_Watts | henrys: Why do we do a separate releases for jbig2 then? | 18:54.35 |
| jo0nas | jbig2 is used in other projects too, independent from ghostscript | 18:54.53 |
| Robin_Watts | And our hope is that ETS will be. | 18:55.03 |
| | so why does it make sense for us to take the "pain" of producing a jbig2 release, but not to take the pain of an ETS release? | 18:55.34 |
| henrys | Robin_Watts: why more pain? | 18:56.22 |
| jo0nas | I recall mumbling that separate jbig2 releases are indeed a pain to you - but I dearly appreciate it! | 18:56.26 |
| Robin_Watts | henrys: It's a tiny bit of pain to produce a release. We have to do that for commercial customers, right? | 18:57.04 |
| | and we don't need to redo a release every 6 months. | 18:57.14 |
| henrys | we can bring it up at the next meeting but if jo0nas would tell what needs to change so he can do his release we can move forward. | 18:57.47 |
| jo0nas | I don't _need_ any change on your part | 18:58.10 |
| | sorry if that was unclear | 18:58.17 |
| | I found the issue, fixed it for Debian re-releases, and share it with you in case you want to tidy your releases similarly | 18:58.50 |
| henrys | jo0nas: what on earth are we talking about then? I thought you had issue with the working of the README.txt | 18:59.04 |
| | s/working/wording | 18:59.18 |
| jo0nas | I already do the "pain" of repackaging your source tarball anyway, because you ship a lot of convenience code copies of other projects, and (not so much anymore - possible none nowadays) some pieces of yours do not fit Debian Free Software Guidelines) | 19:00.18 |
| Robin_Watts | henrys: AIUI jo0nas has stripped gs/tooolbin/halftone/ETS out of his repackaged version. | 19:00.46 |
| | If we fix the wording of the license, then it can be left in. | 19:00.54 |
| jo0nas | henrys: it was unknown to me if the code that I stripped was damaging functionality of ghostscript | 19:01.13 |
| | Robin_Watts: right | 19:01.24 |
| henrys | jo0nas: would you mind creating a bug at bugs.ghostscript.com of everything you strip and why, and we'll have a look at it. | 19:01.29 |
| | ? | 19:01.31 |
| jo0nas | ok, will do! | 19:01.52 |
| henrys | Robin_Watts: even if we do a separate release the wording has to be fixed, right? | 19:02.09 |
| Robin_Watts | henrys: sure. | 19:02.19 |
| jo0nas | henrys: you want me to file bugs about our stripping e.g. libpng, or only the parts stripped due to not complying with Debian Free Software Guidelines? | 19:03.33 |
| henrys | We know about the shared library issues just guideline problems | 19:04.03 |
| jo0nas | ok | 19:04.18 |
| henrys | jo0nas: I assume debian has a policy to always use shared libraries like ubuntu, and I assume you know that is not in line with our recommendations. | 19:05.23 |
| jo0nas | right. And yes, I am aware | 19:05.43 |
| henrys | mvrhel_laptop: it occurs to me Robin_Watts might want to go to this meeting/demo, not sure. | 19:06.07 |
| jo0nas | Ubuntu us a derivative of Debian - so arguably it is the other way around :-) | 19:06.07 |
| henrys | jo0nas: ah true | 19:06.29 |
| Robin_Watts | henrys: the geographical location of this meeting being? | 19:06.36 |
| henrys | Robin_Watts: your house | 19:06.50 |
| | virtual | 19:06.56 |
| Robin_Watts | oh, well, I am happy to make myself available if that will help. | 19:07.12 |
| henrys | Robin_Watts: well I appreciate that your weekend was cut short and I don't want to "pile on" | 19:08.03 |
| Robin_Watts | no, no problem. | 19:08.14 |
| mvrhel_laptop | henrys: I think Miles is doing it on his own. He wanted me to make some videos of the app opening office docs and comparing them to the pdf versions | 19:08.15 |
| | so that is what I was doing this morning. | 19:08.29 |
| | not sure if he is going to use them even | 19:08.40 |
| | I suspect the next meeting may require someone who has a higher knowledge of this | 19:09.20 |
| | i.e. Robin_Watts | 19:09.23 |
| | in any event, I just finished that up and will get back to the windows salt mine | 19:10.41 |
| JakeSays | so i have to say having all the mupdf deps in git sure is a handy convenience | 19:29.52 |
| | how stable is your master branch? | 19:31.32 |
| | Robin_Watts: hey where is the pcl conversion code in mupdf? | 19:41.48 |
| | Robin_Watts: ah n/m. found it | 19:42.58 |
| mackross | Using the latest commit of ghostscript still getting a segmentation fault on a large pdf unless I use -dNOGC | 19:48.04 |
| | I can't run -dNOGC on production can I? | 19:48.58 |
| Robin_Watts | no. | 19:50.05 |
| | Open a bug, and attach the pdf, together with details of the exact command you are using (and the system you are running it on) | 19:50.35 |
| mackross | OK done. It's a 170mb pdf so I've put it on dropbox instead. Thanks for the help so far guys :) | 20:02.12 |
| mvrhel_laptop | bbiaw | 20:31.45 |
| ray_laptop | OK. Done. Pushed the commit and closed bug 680805. Now back to the rest of the stuff on my plate. | 20:54.05 |
| | I sure hope it doesn't cause us to have a 9.12 :-) | 20:54.57 |
| | anybody that uses x11 or x11alpha, please test some transparency files at high resolutions. | 20:55.53 |
| mackross | I'm having trouble compiling on ubuntu from the git commit ray_laptop. I'm getting "Can't compact files with binary postscript byte 152 in!make: *** [obj/gsromfs1_.c] Error 1". I downloaded the tar file. copied out the gs directory. ran `./autogen.sh --disable-cups --disable-gtk --with-drivers=FILES` followed by make. Anything I missed? | 21:24.28 |
| ray_laptop | mackross: that should work. Let me try on my linux box (ubuntu) | 21:36.50 |
| | mackross: building ... | 21:39.21 |
| mackross | ty | 21:40.41 |
| ray_laptop | the build worked fine for me. | 21:43.56 |
| | uname -s: Linux peeved 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux | 21:44.17 |
| | gcc --version: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 | 21:44.38 |
| mackross | hmmm odd | 21:45.43 |
| | I'm on heroku | 21:45.46 |
| | gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3 | 21:45.48 |
| ray_laptop | mackross: can you put your make log (from: make > mk.log 2>&1 ) on pastebin and post the link here ? | 21:45.52 |
| mackross | Ubuntu 10.04 | 21:46.08 |
| | sure | 21:46.10 |
| | I can run you through the commands to do it on heroku pretty easily too. It's only about 5-6 | 21:46.41 |
| ray_laptop | mackross: BTW, that large PDF file just went thru fine on my 32-bit Windoze build | 21:47.18 |
| mackross | Yep goes through fine on my OSX build too | 21:47.42 |
| | which is 64 I think | 21:48.09 |
| ray_laptop | mackross: is your ubuntu 32 or 64 bit ? | 21:48.21 |
| mackross | 64 I believe | 21:48.34 |
| ray_laptop | mackross: post your uname -a | 21:48.44 |
| | (edit it if you are embarrassed about the hostname ;-) ) | 21:49.12 |
| mackross | Linux dd23a66a-23af-41eb-b01d-148492d204e2 3.8.11-ec2 #1 SMP Fri May 3 09:11:15 UTC 2013 x86_64 GNU/Linux | 21:49.15 |
| | hahaha | 21:49.18 |
| ray_laptop | OK, so that _is_ 64 bit | 21:50.13 |
| mackross | yup | 21:50.31 |
| ray_laptop | I'm uploading the file to my linux box now. It'll be a while because we are also loading the net to that box with a monster 500+Gb test database | 21:52.07 |
| mackross | no worries thanks | 21:52.15 |
| | do I need to clean the build that failed? | 21:52.25 |
| ray_laptop | mackross: make clean first is ALWAYS a good idea | 21:52.42 |
| | particularly because it is so quick (relative to the build, at least) | 21:53.15 |
| mackross | true it is quick and the compile error was different the second time round | 21:53.50 |
| ray_laptop | mackross: you might also check your 'df /tmp' mkromfs makes a large .c file | 21:54.22 |
| mackross | It doesn't rely on anything outside of the gs file from the ghostpdl folder does it? | 21:55.38 |
| ray_laptop | mackross: particularly if you've been attempting to run this large file through pdffwrite. That creates /tmp files | 21:55.41 |
| | mackross: mkromfs works in the 'obj' directory | 21:56.32 |
| | but gcc may use /tmp files | 21:56.43 |
| mackross | yep have been using pdfwrite. we're using gs for compressing pdf files that come out of another product which has really shitty compression features | 21:58.26 |
| ray_laptop | upload now at 10% :-/ | 22:00.25 |
| | Oh, should I have use scp -C ?? | 22:00.39 |
| | guess not. zip doesn't shrink it any | 22:02.19 |
| jo0nas | henrys: all current repackaging for Debian is related to convenience code copies. I do not track what I strip anyway, so cannot easily file bugreports about what would have been DFSG-violations had I not stripped that code - I can just see in git history that at least one PDF file part of libjpeg lacks source | 22:07.07 |
| mackross | struggling to get this log file of this heroku dyno. be back as soon as i work out a way | 22:07.48 |
| | off* | 22:07.51 |
| jo0nas | ...speaking of which: there are PDFs currently shipped which I believe also lack source - I will file bugreports if that's indeed the case | 22:08.07 |
| | shipped also in Debian, I mean | 22:08.41 |
| henrys | jo0nas: I'm not sure what you mean PDF is a page description language and interchange format there is not associated source. | 22:10.06 |
| jo0nas | Debian considers as source the "preferred form of editing" by the author of the code - few humans edit the binary PDF material directly - most generate PDF from some other form which is then the "source" from Debian POV | 22:12.14 |
| | examples: doc/GS9_Color_Management.pdf has doc/GS9_Color_Management.tex as source - whereas toolbin/color/icc_creator/example/duotone.pdf lack similar source file | 22:17.24 |
| mackross | ray_laptop well it didn't fit on pastebin so gist link https://gist.github.com/mackross/00599054680d9d2321a0 | 22:18.57 |
| jo0nas | other examples: contrib/color/black.{pdf,ps} and contrib/color/color.{pdf.ps} seems to have a Word document as source, which seems missing from the distributed project | 22:20.13 |
| henrys | jo0nas: I don't know if we want to fool with that, seems rather extreme, but I understand. | 22:27.38 |
| | jo0nas: I'll add it to our agenda for discussion | 22:28.16 |
| jo0nas | I fulyy understand if your find that too nitpicking | 22:29.53 |
| | btw did you see my question about a font issue? | 22:30.39 |
| henrys | jo0nas: no on irc? | 22:31.13 |
| jo0nas | (19:53:47) jonas: another issue (experienced with 9.07): Ghostscript fails if a PDF references an unknown font and there's WOFF files in fontconfig path - see https://bugs.debian.org/732440 | 22:31.18 |
| | (19:54:13) jonas: is that issue known to you - and perhaps even fixed by now? | 22:31.18 |
| henrys | no idea report a bug and probably chrisl will look at it. Or has he already weighed in? | 22:33.30 |
| ray_laptop | mackross: Did you untar the snapshot into a clean directory ? The make log shows some garbage files: | 22:52.29 |
| | node 'Resource/CIDFSubst/._DroidSansFallback.ttf' len=176 1 blocks, compressed size=105 | 22:52.31 |
| | node 'Resource/CIDFont/._ArtifexBullet' len=176 1 blocks, compressed size=105 | 22:52.32 |
| mackross | I'm fairly sure. I'll redo though. | 23:21.47 |
| ray_laptop | mackross: I don't see those files (with the ._ prefix) in my build log | 23:33.58 |
| mackross | Like _ArtifexBullet? | 23:35.19 |
| ray_laptop | yep | 23:36.14 |
| mackross | Hmm the tar file I'm using is just the gs folder which I copied out of the snapshot and recompressed: https://s3-us-west-1.amazonaws.com/static-heroku-files.happyinspector/gs9.10.master.tar.gz | 23:36.48 |
| ray_laptop | and the sizes (176 byts) are funky | 23:36.55 |
| | the section of my makefile log has: | 23:42.38 |
| | node 'Resource/CIDFSubst/DroidSansFallback.ttf' len=3727996 228 blocks, compressed size=1877489 | 23:42.44 |
| | node 'Resource/CIDFont/ArtifexBullet' len=2667 1 blocks, compressed size=1359 | 23:42.45 |
| | node 'Resource/CMap/KSC-Johab-H' len=69491 5 blocks, compressed size=28255 | 23:42.47 |
| mackross | Hmmm ok | 23:49.31 |
| | I'll try hunt that down | 23:49.34 |
| | I'm going to download the whole tar file to the heroku dyno and try it on there maybe they're OSX files? | 23:53.53 |
| | Forward 1 day (to 2014/01/30)>>> | |
IRC Logs