| | <<<Back 1 day (to 2012/04/04) | 2012/04/05 |
| ray_laptop | grrrr... Between my laptop crashing and vagaries of "git" (been trying to use git bisect) my local git repos is honked up. :-( | 03:13.52 |
| | it won't show ever show me at 'master' -- just shows me at the some rev (6e7d591...) and won't work with updating or pull or anything | 03:15.21 |
| | guess I have to pull a new clone :-( | 03:15.36 |
| kens | Hello Robin_Watts I know you're awake, I can see you've started a cluster test. Welcome home | 09:37.41 |
| Robin_Watts | Morning kens | 09:37.47 |
| Robin_Watts | uncorks the email bottle... | 09:38.29 |
| | It seems Scott has just nailgunned his hand :( | 09:39.04 |
| kens | Err, what ? | 09:40.02 |
| Robin_Watts | He slipped :( | 09:40.21 |
| kens | Ouch :-( | 09:40.31 |
| | I guess he didn't email everyone (or GMail is not telling me) | 09:40.47 |
| Robin_Watts | facebook. | 09:40.52 |
| kens | Ah. | 09:40.57 |
| | Robin_Watts : feel up to answering a couple of stupid simple Git questions ? | 09:41.20 |
| Robin_Watts | Go for it. | 09:41.27 |
| kens | I want to do a branch | 09:41.33 |
| | because this memory stuff is getting too extensive and complex. | 09:41.43 |
| | Later I will want to put the changes back in the trunk, so I don't want a public branhc | 09:41.58 |
| | Do you know a good way to go about this ? | 09:42.13 |
| | Bearing in mind that I want to merge the code later and delete the branch | 09:42.31 |
| Robin_Watts | kens: Yeah. | 09:42.55 |
| | Just git checkout -b tmp_mem_branch | 09:43.15 |
| kens | Hmm seems easy :-) | 09:43.26 |
| | Can I pull changes from master into there ? | 09:43.35 |
| Robin_Watts | Yes. | 09:43.41 |
| kens | Even better | 09:43.46 |
| | Thanks. | 09:43.52 |
| Robin_Watts | personally I do it by changing back to master (git checkout master) | 09:44.01 |
| | then pulling into master. | 09:44.08 |
| kens | OK that seems a good appraoch. | 09:44.20 |
| Robin_Watts | then going back to the temp branch (git checkout tmp_mem_branch) | 09:44.23 |
| kens | As soon as this build finishes I'll go for it | 09:44.28 |
| Robin_Watts | then rebasing on master. | 09:44.30 |
| | (git rebase master) | 09:44.35 |
| | That moves ALL your branch up so that it's at the tip of master. | 09:44.44 |
| kens | writes this down | 09:44.49 |
| Robin_Watts | So then when I'm happy with everything, I can just change back to master (git checkout master) | 09:45.04 |
| kens | Hmm, and then my btanhc wioll be at the tip ? So I can just push it ? | 09:46.00 |
| Robin_Watts | then all my new branch is effectively sat at the tip of master, so I can just commit all of that to master in one hit. | 09:46.06 |
| kens | :-) | 09:46.13 |
| Robin_Watts | There are several ways to do that. | 09:46.14 |
| | I *think* git rebase tmp_mem_branch should do it. | 09:46.30 |
| | but if not, you can git update-ref or something. | 09:46.43 |
| kens | I may ask more dumb questions when I get to that point ;-) | 09:47.13 |
| Robin_Watts | no worries. | 09:49.19 |
| kens | Next question; Is it OK if I commit a changed .gitignore which ignores the memnto directories ? | 09:52.38 |
| Robin_Watts | kens: sure. | 10:03.07 |
| kens | THanks robint I'll do that. Its been annoying me :-) | 10:03.22 |
| Robin_Watts | Morning paulgardiner | 10:06.26 |
| paulgardiner | Robin_Watts: Hi. Got a moment? | 10:10.55 |
| Robin_Watts | Sure. | 10:11.02 |
| paulgardiner | I need to alter streams of tokens: take a stream and replace a single token with a different one, or locate markers and replace everything between. I can think of two ways: locate the position of the tokens in a buffer and manipulate the buffer, or read the stream of tokens and regenerate it with the changes. | 10:12.59 |
| | I prefer the first, but pdf_lex() doesn't seem to give me a way to locate things in a buffer. | 10:13.21 |
| | .. welcome back, by the way. :-) | 10:13.32 |
| Robin_Watts | Right. This is for appearance stream synthesis. | 10:14.00 |
| paulgardiner | I don't want to do my own lexing when we already have pdrf_lex | 10:14.04 |
| | Yes. That's right. | 10:14.11 |
| Robin_Watts | AIUI, the appearance stream synthesis always involves 'replace between X and Y with Z'. | 10:14.40 |
| paulgardiner | An example: ... | 10:14.44 |
| | hang on I'm finding a file | 10:15.10 |
| Robin_Watts | Oh, but there is ctm fiddling too, etc? | 10:15.27 |
| paulgardiner | ctm? Is that the matrix? | 10:16.01 |
| Robin_Watts | yes, sorry. | 10:16.36 |
| | ctm = current transformation matrix. That's postscript terminology, I think. | 10:16.57 |
| paulgardiner | Example "/Helv 0 Tf" means calculate a font size that fits. I want to turn it into "/Helv 10 Tf" say, but I don't want to make assumptions about the exact form so I want to lex correctly. | 10:17.11 |
| | The matrix is set up by adding it to the stream. | 10:17.27 |
| | Currently I'm thinking that reading the stream of tokens and regenerating it, writing the result into an fs_buffer is the way to go, but there may be existing stuff I'm not aware of. | 10:19.23 |
| Robin_Watts | paulgardiner: I wrote some code ages ago that vectorised the pdf interpretation stuff. | 10:20.02 |
| | So that as we interpret a buffer, rather than it having a big switch that called pdf_op_ctm it called an array of function pointers. | 10:20.37 |
| | pdf_op_XXX I mean, where XXX is the token. | 10:21.00 |
| | The idea being that we could easily replace the implementations by replacing the array. | 10:21.26 |
| | But that never got adopted - don't know if that would help or hinder here. | 10:21.44 |
| | Let me have a quick dig in the spec again. | 10:21.55 |
| | Where in the spec is the stuff about 0 sized fonts meaning calculate a size that fits ? | 10:23.53 |
| paulgardiner | In the example above it would be nice to just find where the "Tf" is and then insert "10" in place of the token preceding it, but I feel I should be using pdf_lex to find the "Tf" and I cannot see how to get pdf_lex to tell me whare it found the token. | 10:24.10 |
| | That's the one yes, although just an example. General manipulation of a stream of tokens is needed. | 10:24.46 |
| Robin_Watts | pdf_lex reads frm a stream and returns a token. | 10:24.57 |
| | It's not designed to tell you anything about the underlying buffer. | 10:25.20 |
| paulgardiner | Oh and can I get Chatzilla to insert "Robin_Watts;" for me in these conversations? | 10:25.40 |
| Robin_Watts | it deliberately hides the underlying representation as bytes from you. | 10:25.45 |
| | Not without typing Ro<TAB> each line :) | 10:26.10 |
| paulgardiner | That's what I thought. So is reading the stream as tokens and regenerating with the alterations sensible? | 10:26.21 |
| Robin_Watts | paulgardiner: It doesn't sound completely stupid to me, certainly. | 10:26.39 |
| paulgardiner | Ah the tab will help a lot. Thanks | 10:26.41 |
| Robin_Watts | I reckon there are 2 possible ways to go here. | 10:26.48 |
| | 1) Operate entirely at the character level; that means redoing the work that pdf_lex does. | 10:27.12 |
| | "Just" parse the underlying buffers yourself, doing substitution etc. | 10:27.33 |
| | or 2) Use pdf_lex to get you tokens and regenerate from that. | 10:28.13 |
| | That frees you from the need to recode the parsing stuff, but may possibly mean you need a slightly more complex state machine. | 10:28.46 |
| paulgardiner | Yeah. 1 isn't too bad for the two cases I am currently looking at, but 2 sounds like it might be less error prone and neater. | 10:29.04 |
| Robin_Watts | I suspect for simple cases 1 is easier, but ultimately we may end up needing to make 1) as complex as pdf_lex, so 2) would be a better option. | 10:29.35 |
| | brb | 10:29.48 |
| paulgardiner | Yeah good. That's my feeling too,. | 10:29.55 |
| | Well there is option 3, which is to update pdf_lex so that it is possible to find where in the stream the last token came from, but that complicates pdf_lex for the sake of this one way of using it. | 10:31.38 |
| Robin_Watts | I'd be reluctant to amend pdf_lex, because it's the rate determining step in lots of cases, I think. | 10:38.31 |
| | So anything that slows it down (however little) is bad. | 10:38.46 |
| paulgardiner | Yeah that's what I was thinking. | 10:39.15 |
| | I reckon regeneration is a good way to go. I bet there are already ways to open an fz_buffer as a stream and write tokens to it. | 10:39.47 |
| | And if there isn't, it would be a generally useful thing to add | 10:40.19 |
| Robin_Watts | I don't believe there are, but yes, it's a reasonable thing to want to add. | 10:40.52 |
| | An fz_buffer is a very simple object. | 10:41.10 |
| paulgardiner | Yes. Lots of MuPDF seems nice and cleanly done. | 10:42.31 |
| Robin_Watts | Tor's slogan is "No Bloat" :) | 10:43.38 |
| paulgardiner | That figures :-) | 10:44.00 |
| Robin_Watts | paulgardiner: Random thought.... | 11:11.30 |
| | If we have an appearance stream in the document, and you come along and replace it with a synthesised one, that replaces a 0 Tf thing with a real size, what happens when we edit it again? | 11:12.26 |
| | There won't be a 0 Tf left, so we won't be able to update it a second time? | 11:12.53 |
| | Or are you keeping the original AP around somewhere and regenerating from that each time ? | 11:13.08 |
| paulgardiner | There may be problems like that, but this particular case is ok because the 0 Tf is in the string corresponding to the DA tag in one of the dicts (tag is probably the wrong word). I'll be leaving the DA string as is, just using an altered version of it in each appearance stream derived. | 11:15.52 |
| Robin_Watts | Right. | 11:18.05 |
| | paulgardiner, sebras, anyone-else: Did tor8 state his intention for the 'unstable' branch? | 11:28.31 |
| | Is the idea that we should be putting stuff on that rather than master until 1.0 ? | 11:28.55 |
| paulgardiner | Robin_Watts: Sorry, I didn't notice any comments about it. | 11:30.45 |
| Robin_Watts | me either. | 11:30.52 |
| | I've put a fix on master, but it seems like it's one we want in 1.0, so... | 11:31.12 |
| paulgardiner | Robin_Watts: ping | 12:10.38 |
| Robin_Watts | pong | 12:11.34 |
| paulgardiner | Regeneration isn't going to work so well. I have a varation on it that will work, but it's a bit odd. Well the regeneration works for one case, but the variation is needed for the other. | 12:13.32 |
| Robin_Watts | This sounds like something that will work faster by phone... :) | 12:13.58 |
| paulgardiner | The problem is that pdf_lex doesn't spit out tokens, it leaves info about the current token in buffers and the info is deistroyed on next call | 12:14.16 |
| tannerwatson | hey guys | 13:20.07 |
| | stupid noob question | 13:20.12 |
| | im pulling down the source right now | 13:20.54 |
| kens | For what ? | 13:21.01 |
| tannerwatson | oh, for ghostscript sorry | 13:21.11 |
| kens | MuPDF ? Ghostscript ? GhostpCL ? | 13:21.13 |
| | :-) OK | 13:21.17 |
| tannerwatson | is there a method in the header like "gsapi_init_with_args" but only without args? | 13:21.35 |
| | oh......i dont know one sec....this is the first time me using the library and im using it from c#......please dont hate me | 13:22.02 |
| kens | Not that know of, why not just callit with no arguments ? | 13:22.04 |
| tannerwatson | im trying to use the gsdl32.dll within a c# application to batch convert about 200+ PDFs to TIFF format | 13:22.46 |
| kens | OK but you will need to pass *some* arguemtns, the name of the input file if nothing else ;-) | 13:23.10 |
| | BTW I know *nothing* about C# | 13:23.23 |
| tannerwatson | no, that helps | 13:23.52 |
| | im just impartient an my internet connection is slow.....so i though id ask while im cloning the repo | 13:24.31 |
| kens | Cloning Giyt repos does take some imte, but its fast to use afterwards | 13:24.56 |
| tannerwatson | oh yes, im in love with git | 13:25.34 |
| kens | The gs_api_* functions appear to be defined in ghostpdl/gs/psi/iapi.h there is only one init function that I can see | 13:25.49 |
| tannerwatson | im working with a client that still uses SVN and its rediculous how slow it is | 13:25.49 |
| | oh ok | 13:26.07 |
| | thanks a lot, that points me in the right direction as to where to look | 13:26.21 |
| kens | NP | 13:26.25 |
| tannerwatson | do you see anything in the header regarding batch procession/providing multiple input files to convert all at once instead of making multiple calls to the library? | 13:27.14 |
| kens | There are no provisions for that at all | 13:27.29 |
| tannerwatson | *sad face* :( | 13:27.55 |
| kens | You can do it from the command line, just put each file there, so probably you can do it with 'inti_with_args' as well. | 13:28.20 |
| tannerwatson | we are hitting a memory leek when converting > 100 PDFs to tiff | 13:28.21 |
| | aaahhhh, that might do it then. Ill double check the documentation | 13:28.43 |
| kens | memory leaks should be reported as a bug really. | 13:28.44 |
| tannerwatson | @kens BTW you are fucking amazing | 13:28.58 |
| kens | But how are you rendering 100 PDF files to tiff at the moment ? | 13:29.12 |
| tannerwatson | yeah, i will once I figure out the exact issue. right now i dont really know if its the libraries fault or .Net/C#s | 13:29.22 |
| kens | We do have people using GS in 'servere mode' where tehy chuck lots of files art it without restarting | 13:29.47 |
| tannerwatson | just making multiple calls to the library..........oh really? | 13:30.06 |
| kens | If there were memory leaks I would expect that to show it up, but it may depend on the files and envronemtn | 13:30.06 |
| | My typing is bad today :-( | 13:30.20 |
| tannerwatson | do you know of a link that has more information regarding "server mode' so I can do the research? | 13:30.35 |
| | no worries sir | 13:30.46 |
| | you've already been a huge help | 13:31.00 |
| kens | On Windows you jhust use hte API and the DLL. But you don't *have* to operate that way | 13:31.02 |
| | You can staticlaly link the GS library, or of course define a new DLL, you don't have to use ours. | 13:31.21 |
| kens | is not the expert in using GS this way, unfortunately | 13:32.12 |
| tannerwatson | ill take a look :D | 13:32.44 |
| kens | try ghostpdl/gs/pis/dwnodll.c for a 'non-DLL' example | 13:33.08 |
| | p/pis/psi/ | 13:33.15 |
| chrisl_away | forgot to rest his status....... | 13:33.16 |
| kens | Hmm, or maybe not | 13:33.35 |
| chrisl | I'm not sure we have a non-dll Windows example, now do we? | 13:34.14 |
| kens | I thought we did, I'm obviously mimstaken | 13:34.27 |
| | OK so I think you can do 'gsdll.init_with_args to start GS up | 13:35.02 |
| chrisl | Even if we do have one, I'd treat it with extreme caution....... | 13:35.08 |
| kens | THen for each file do gsdll.run_string | 13:35.15 |
| | then when complete do gsdll.exit | 13:35.26 |
| chrisl | kens: do you need to add an explicit save/restore around each file - I've seen some example code did that | 13:36.29 |
| kens | Well you are doing run_string so I guess you could add it there, assuming the string you run is PostScript :-) | 13:36.56 |
| tannerwatson | yup, thats what im currently doing | 13:36.57 |
| | ooohhh, ok | 13:37.10 |
| kens | It certainly won't do any harm | 13:37.13 |
| tannerwatson | didnt see the run_string | 13:37.18 |
| | ill be on hte channel all day and Ill let you know what we come up with | 13:38.34 |
| | good job with the library and thanks a lot :D | 13:38.40 |
| kens | Really Ray should be here to answer these kinds of questions ;-) | 13:38.41 |
| tannerwatson | ill keep a look out for him :) | 13:40.05 |
| kens | He's in Los Angeles, so it will be a few hours yet | 13:40.26 |
| tannerwatson | ill still be here, i have to figure out why our memory leak by the end of the day | 13:41.29 |
| | and sadly, i know very little about c and c++ .......... | 13:42.00 |
| kens | No C++ in Ghostscript :-) | 13:42.25 |
| Robin_Watts | tannerwatson: For tracking the memory leak you may want to look into using Memento. | 13:42.58 |
| | We have a little library included in the C source that tracks memory problems (like leaks, overwrites etc). | 13:43.51 |
| | I don't know what platform you're on, but the Windows solution has a Memento configuration, and the unix makefiles have a memento target. | 13:44.35 |
| tannerwatson | @robin is that a separate project or is it in the GS repo? | 13:44.45 |
| | im on Windows :( C# application | 13:44.55 |
| Robin_Watts | It's included as part of the standard code. | 13:45.03 |
| tannerwatson | kk, thank ill take a look once i finish cloning the repo | 13:45.16 |
| Robin_Watts | So presumably you are building the lib using our standard VS project ? | 13:45.18 |
| | s/project/solution/ | 13:45.25 |
| tannerwatson | no, im just linking (i think thats the correct term) to the gsdll32.dll from within a VS project | 13:46.19 |
| kens | I think we need ray_laptop to answer questions about server mode. I see imainarg.c doing the work of hanlding the files on the command line | 13:46.48 |
| tannerwatson | similar to this http://www.mattephraim.com/blog/2009/01/06/a-simple-c-wrapper-for-ghostscript/ | 13:46.53 |
| Robin_Watts | tannerwatson: Right. so to use Memento you'd need to build your own version. | 13:47.22 |
| | (i.e. you can't just use a prebuilt gsdll32.dll from a binary installation as that's a release build) | 13:47.57 |
| tannerwatson | kk, that wont be a problem....i at least know how to do that :) | 13:48.00 |
| kens | Our code converts the filename to an escaped hex string, prepends and appends some stuff and then feeds it to run_string. | 13:48.37 |
| | I woudl guess this is imply doing "<filename> run" but making a hex string. | 13:49.03 |
| | In fact we do "filename .runfile" | 13:49.32 |
| | But we conver the filename into an escaped Hex string. | 13:50.07 |
| tannerwatson | OMG my internet connection is so slow.....still on only 16%..... *sigh* | 13:50.45 |
| Robin_Watts | kens, chrisl, paulgardiner: CMAP question if I may. | 14:31.54 |
| kens | Go | 14:32.05 |
| chrisl | Uh-oh.... | 14:32.06 |
| paulgardiner | ah ha | 14:32.12 |
| kens | hopes its simple | 14:32.26 |
| Robin_Watts | I've got a cmap in this pdf file that has various beginbfchar sections. | 14:32.32 |
| | In one of them I have <0003> <0020> | 14:32.47 |
| kens | Yes.... | 14:32.55 |
| Robin_Watts | and in another I have <0003> <00a0> | 14:32.58 |
| kens | That looks illegal | 14:33.09 |
| Robin_Watts | That seems to me like it's trying to map <0003> to more than one place, right? | 14:33.16 |
| kens | I don't think ranges can overlap | 14:33.19 |
| Robin_Watts | OK, that's a good answer. | 14:34.00 |
| chrisl | No, ranges can't overlap | 14:34.04 |
| Robin_Watts | OK, so I can modify our code to just ignore the second one. | 14:34.47 |
| | Thanks. | 14:35.01 |
| | We never drive cmaps backwards, then ? | 14:35.26 |
| kens | You're not supposed to | 14:35.41 |
| chrisl | Hmm, my initial feel would be that the second one would take priority | 14:35.57 |
| kens | I suspect it does in Adobe implementations | 14:36.12 |
| Robin_Watts | I suspect I don't care whether first or second take priority - the main thing is that only one counts :) | 14:37.23 |
| kens | I'm sure you can't have 2 | 14:37.35 |
| | Thoguh I can't find my copy of the CMap spec right now | 14:38.04 |
| chrisl | Well, generally the *later* settings would overwrite the earlier ones - but given that this shouldn't happen, all bets are off, rather | 14:38.21 |
| paulgardiner | Robin_Watts: AFAIKS another PDF library we know of would overwrite the first with the second. | 14:41.12 |
| Robin_Watts | The problem I'm seeing here is that mupdf reads cmaps in then compacts them to save space (and be faster to lookup) | 14:41.59 |
| | and that compaction process is getting confused by the presence of multiple entries, giving the wrong output chars. | 14:42.31 |
| | So any fix I pick that stops the garbling will be fine, I suspect. | 14:42.47 |
| chrisl | Ah, from the spec.: "Ranges need not be contiguous, but cannot overlap" | 14:42.59 |
| | And later: "Note Overlapping codespaces are not permitted." | 14:43.44 |
| | kens: ping | 15:02.27 |
| henrys | welcome back Robin_Watts | 15:04.37 |
| Robin_Watts | henrys: Thanks. | 15:04.46 |
| kens | chrisl pong | 15:10.04 |
| chrisl | is your phone free? | 15:10.16 |
| kens | yes I believe so | 15:10.21 |
| | Indeed yes | 15:10.40 |
| chrisl | OKay, I'll find your number..... | 15:10.49 |
| kens | henrys will you reply about the HPGL/2 questions ? | 15:10.56 |
| henrys | yes | 15:11.29 |
| kens | Thanks :-) | 15:11.35 |
| Robin_Watts | Actually, this CMAP stuff may be a red herring :( | 15:20.42 |
| | I look up the code 0x29 from the string and that returns a ucs value of 0x46 (which is 'F') | 15:21.35 |
| | But when I ask freetype to render gid = 0x29, we get 'H' rather than 'F'. | 15:21.58 |
| kens | CIDToGIDMap ? | 15:32.32 |
| henrys | kens:I was intending to investigate exactly what he is asking anyway so hopefully I'll get something to him in a day or two. | 15:36.14 |
| Robin_Watts | kens: http://bugs.ghostscript.com/show_bug.cgi?id=692943 | 15:36.16 |
| | The reduced file is on there. | 15:36.32 |
| | If someone with more fonty knowledge than me could spare a second to look, I'd be grateful. | 15:36.49 |
| kens | will look now | 15:37.06 |
| Robin_Watts | Interestingly, gs gets it right, but it burbles a lot of rubbish about CID fonts. | 15:37.09 |
| henrys | mvrhel:he's really going to create a mess - he'll have to integrate pcl with his 8.? ghostscript because he never upgraded. Sigh. | 15:38.47 |
| mvrhel | yuck! | 15:38.57 |
| | I don't want any of those bugs assigned to me | 15:39.27 |
| kens | There are some ridiculously large numbers in the CMap | 15:40.55 |
| | Robin_Watts : The character code 0x29 maps to CID 0x46 according to your CMap. | 15:42.24 |
| Robin_Watts | 0x46 being 'F'. | 15:42.34 |
| kens | So why are you expecting FreeType to render 0x29 as an F ? | 15:42.44 |
| Robin_Watts | Sorry? | 15:43.11 |
| kens | chrisl terlls me the string is 0x29 :-) | 15:43.28 |
| Robin_Watts | The string us <0029> yes. | 15:43.38 |
| kens | character code 0x29 maps to CID 46. You should supply the 0x46 to FreeType I would have thought | 15:44.11 |
| Robin_Watts | We have an identity cmap in place, so the gid = 29. | 15:44.19 |
| kens | What ? Its not using the UCS2 CMap ?> | 15:44.33 |
| Robin_Watts | And we have a tounicode cmap that maps 29 to 0x49 | 15:44.36 |
| | And we have a tounicode cmap that maps 0x29 to 0x46 (sorry) | 15:44.49 |
| kens | Oh, that's teh ToUnicode, OK forget me then | 15:44.50 |
| Robin_Watts | So, we call freetype and ask it to render gid = 29, and we get H, rather than F. | 15:45.16 |
| kens | OK yes, (rewinds to top of file) looks like it shoudl be 0x29 to FreeType | 15:45.29 |
| Robin_Watts | So, maybe this is a freetype bug? | 15:45.36 |
| kens | Well you aren't using teh same font | 15:45.45 |
| Robin_Watts | Maybe gs is saved by the fact it's using the incremental interface? | 15:45.54 |
| kens | Because the font isn't embedded | 15:45.56 |
| | What font are you *actually* using ? | 15:46.10 |
| | DroidSans ? | 15:46.15 |
| Robin_Watts | droidsans I would assume. | 15:46.21 |
| kens | I wonder if GS is using Arial | 15:46.31 |
| | chrisl says no | 15:46.43 |
| Robin_Watts | gs is using droid sans fallback, I believe | 15:46.46 |
| | Can't find CID font "Arial". | 15:46.57 |
| | Attempting to substitute CID font /Adobe-Identity for /Arial, see doc/Use.htm#CIDFontSubstitution. | 15:46.59 |
| | The substitute CID font "Adobe-Identity" is not provided either. attempting to use fallback CIDFont.See doc/Use.htm#CIDFontSubstitution. | 15:47.01 |
| | Loading a TT font from %romesource/CIDFSubst/DroidSansFallback.ttf to emulate | 15:47.03 |
| | a CID font Adobe-Identity ... Done. | 15:47.04 |
| kens | Well, I'd have to debug both programs to see why MuPDF isn't working I'm afraid. It could be a difference in teh way we setup the font. | 15:48.00 |
| chrisl | Ghostscript is passing decimal 41 into Freetype | 15:51.50 |
| Robin_Watts | Which is 0x29 | 15:52.29 |
| chrisl | Robin_Watts: look at how the cmap tables are selected in MuPDF | 15:52.36 |
| kens | TT CMAP subtables | 15:52.50 |
| Robin_Watts | ducks as that goes shoots right over his head. | 15:52.59 |
| chrisl | I can look at it tomorrow, if you want | 15:53.18 |
| Robin_Watts | chrisl: I wonder whether that would be faster than trying to explain it to me :) | 15:53.52 |
| chrisl | Robin_Watts: I think MuPDF gets the choice between the 3.1, 3.10 and 1.0 cmap tables wrong | 15:54.32 |
| Robin_Watts | what cmap tables are you talking about? Are you saying that mupdf should be telling freetype something before calling it? | 15:54.35 |
| | Ah. | 15:54.37 |
| | Is there a freetype function that I can hunt for that gs is calling correctly and mupdf is not calling/is calling wrongly ? | 15:54.59 |
| chrisl | I'll check it out after I get off the phone with Ken | 15:55.17 |
| Robin_Watts | thanks. | 15:55.24 |
| chrisl | Robin_Watts: MuPDF seems to be using the Helvetica font, not the DroidSansFallback CIDFont substitute - but still looking...... | 16:13.53 |
| Robin_Watts | mvrhel: ping | 16:20.01 |
| mvrhel | Robin_Watts: pong | 16:20.13 |
| Robin_Watts | Someone has reported a problem with the mupdf halftone stuff. | 16:20.22 |
| mvrhel | oh. and you just copied my stuff... | 16:20.51 |
| Robin_Watts | We basically render to 8 bit contone greyscale, and then I apply the same threshold stuff that you do in gs. | 16:20.52 |
| mvrhel | ok. I would be interested to see the issue | 16:21.09 |
| Robin_Watts | It's a much simpler version of your stuff. | 16:21.14 |
| | Essentially he has black stuff coming out with the occasional white dot in it. | 16:21.32 |
| | I output a black pixel, if pixmap < threshold. | 16:21.54 |
| mvrhel | oh. hmm. sounds like either a <= , < or a table value issue | 16:22.06 |
| Robin_Watts | And my threshold table contains values from 0 to 0xff inclusive. | 16:22.13 |
| | Yes, indeed. | 16:22.37 |
| | If I put <= then I get black spots in the white. | 16:22.47 |
| mvrhel | hehe.. yes. usually you avoid having both 0 AND ff in the table | 16:23.10 |
| Robin_Watts | Right. | 16:23.19 |
| | So... which do you avoid ? | 16:23.29 |
| mvrhel | good question | 16:23.39 |
| Robin_Watts | (I think I got my threshold table from you) | 16:23.42 |
| mvrhel | let me check | 16:23.43 |
| | oh that is not good | 16:23.49 |
| | so you used my table generation tools? | 16:24.13 |
| Robin_Watts | I have a fix here (I now check for *pixmap ==0 || *pixmap < *ht_line++) | 16:24.24 |
| | mvrhel: I didn't call your generation tools. | 16:24.37 |
| | I think either you mailed me it, or I stole it from somewhere of yours. | 16:24.55 |
| mvrhel | oh. | 16:24.59 |
| Robin_Watts | So, the problem may well be mine. | 16:25.12 |
| mvrhel | what size is your table? | 16:25.33 |
| Robin_Watts | It would be nice to solve it in the same way that gs does for consistency though. | 16:25.36 |
| mvrhel | yes | 16:25.46 |
| Robin_Watts | 16x16 | 16:25.53 |
| | my comment says: | 16:25.56 |
| mvrhel | ok. let me make one and see what it creates | 16:26.06 |
| Robin_Watts | /* Default mono halftone, lifted from Ghostscript. */ | 16:26.09 |
| | So maybe that predates your new stuff. | 16:26.25 |
| mvrhel | hmm oh you got it from the resources probably | 16:26.26 |
| | yes | 16:26.28 |
| Robin_Watts | but if I got that from the resources, then how does gs cope with having both 0xff and 0 in the same table? | 16:27.11 |
| mvrhel | good question | 16:27.20 |
| kens | Time to go, goodnight all | 16:27.30 |
| mvrhel | Robin_Watts: give me a few minutes | 16:27.44 |
| Robin_Watts | Thanks. | 16:27.49 |
| Robin_Watts | will fetch tea. | 16:27.58 |
| | Looks like it's from gs_init.ps | 16:39.21 |
| | I wonder if there is some magic in the postscript stuff around it that avoids the problem... | 16:39.45 |
| mvrhel | yes. I was looking at that | 16:39.48 |
| | yes exactly I was wondering the same | 16:39.56 |
| | I was trying to catch the threshold getting applied in the code now, but having issues.... | 16:40.23 |
| Robin_Watts | mvrhel: OK, look, don't let me waste any more of your time on this. | 16:40.48 |
| | The way this is used in mupdf (or at least the idea of it) is that people can supply their own threshold arrays. | 16:41.16 |
| mvrhel | sounds like a good idea | 16:41.29 |
| Robin_Watts | So I probably need to cope with them putting both 0 and ff into the array. | 16:41.31 |
| mvrhel | well, I would not | 16:41.45 |
| | they may want to do that for some reason | 16:41.53 |
| Robin_Watts | Hence I need something like my pix == 0 || pix < thresh | 16:41.57 |
| | mvrhel: Oh, you think I should just stick with pix < thresh and be done with it ? | 16:42.25 |
| mvrhel | yes | 16:42.30 |
| | and fix the default array | 16:42.38 |
| | you could if you want just slightly rescale the array you have | 16:42.59 |
| Robin_Watts | Not sure how I can really rescale it. | 16:43.35 |
| mvrhel | well you have values from 0 to 255 | 16:43.51 |
| Robin_Watts | It's 256 different values held in chars :) | 16:44.00 |
| | so there is limited room for rescaling. | 16:44.06 |
| mvrhel | I mean off line | 16:44.18 |
| Robin_Watts | fixing the default array would simply be me changing the 00 entry to 01, I think. | 16:44.29 |
| | offline? | 16:44.36 |
| mvrhel | Robin_Watts: yes, for now, I would just change the 00 values to 01 | 16:45.02 |
| Robin_Watts | Ok, thanks. | 16:45.17 |
| mvrhel | and add a comment in the code that since you are using < values of 0 should not be in the array | 16:45.23 |
| Robin_Watts | Have done. Thanks. | 16:48.00 |
| mvrhel | cool | 16:53.13 |
| chrisl | Robin_Watts: font problem? | 16:54.34 |
| Robin_Watts | chrisl: Yes? | 16:54.45 |
| chrisl | Problem is simple, solution slightly less so........ | 16:54.58 |
| | The problem is we're being asked for the Arial,Bold *CIDFont* and we're loading a substitute for the Arial *font* - you can't substitute a CIDFont with a font | 16:55.47 |
| Robin_Watts | OK. | 16:57.38 |
| chrisl | So the solution is to separate the logic for substituting fonts and CIDFonts. | 16:57.55 |
| Robin_Watts | OK. That's an area of the code I have almost no experience in, so I may wait for tor8 to come back. | 16:58.46 |
| chrisl | If I hack up the code to load DroidSansFallback (instead of Helvetica) I get the right glyph in your cutdown test - yeh, I think this needs Tor's input | 16:59.09 |
| | Robin_Watts: do you want me to put all that in the bug? | 16:59.59 |
| Robin_Watts | chrisl: If you wouldn't mind - you're likely to write less gibberish than me :) | 17:00.28 |
| chrisl | Hmm wouldn't bet on that - but at least Tor can ask me about it when he's ready to look at it.... | 17:00.57 |
| nicoo | Hi | 17:03.46 |
| Robin_Watts | nicoo: hi | 17:04.01 |
| nicoo | I'm trying to build opdf, which depends on mupdf's pdfdraw. It seems to have been renamed to mudraw, but I can't find any way it's packaged, or supposed to be installed | 17:04.50 |
| ray_laptop | this crashing is _really_ getting tiresome | 17:04.51 |
| chrisl | ray_laptop: I thought Windows was supposed to be stable these days??? | 17:05.20 |
| nicoo | I just managed to find it lives under mupdf/apps | 17:05.28 |
| ray_laptop | I had to pull a new git repo clone because the old one got honked up | 17:05.31 |
| nicoo | chrisl: s/stable/a bit less unstable/ | 17:05.59 |
| chrisl | nicoo: :-) | 17:06.13 |
| ray_laptop | chrisl: I'm beginning to suspect that it's hardware, but not sure | 17:06.56 |
| chrisl | ray_laptop: I think you're probably right - it seems to be happening an awful lot (even for Windows!) | 17:07.29 |
| ray_laptop | I think I'll keep to repos around -- it's handy to have one to use for bisecting and another that I can continue to work on | 17:07.34 |
| Robin_Watts | nicoo: pdfdraw has indeed been renamed to mudraw. | 17:07.37 |
| | It's not "packaged" as such. We supply unix makefiles and a windows solution, but we don't 'install' etc (AFAICR) | 17:08.32 |
| chrisl | ray_laptop: you'd already finished when I came online: I suspect you maybe just needed a "git bisect reset" | 17:08.35 |
| ray_laptop | nicoo: they did that just to make sure people were reading the docs ;-) | 17:08.45 |
| nicoo | Robin_Watts: I didn't see any make target named apps, mudraw or something like that | 17:09.16 |
| | Ok | 17:09.25 |
| | ray_laptop: Where is the relevent doc, then § | 17:09.35 |
| ray_laptop | chrisl: no -- it didn't say 'BISECTING' -- but it may be OK -- after a couple of reboots I was able to checkout master | 17:09.40 |
| nicoo | s/§/?/ | 17:09.42 |
| Robin_Watts | nicoo: Just 'make' :) | 17:09.43 |
| ray_laptop | nicoo: that information requires security clearance ;-) | 17:10.30 |
| nicoo | xD | 17:10.39 |
| chrisl | ray_laptop: okay, as long as you got it sorted. FWIW, I keep at least two repositories on the go. | 17:11.00 |
| ray_laptop | chrisl: I think I will now, too | 17:11.20 |
| nicoo | Hmm, strange; I have a working mupdf install on my system (0.9), but the git version doesn't build here | 17:12.08 |
| | Log here : http://paste.pocoo.org/raw/576584/ | 17:13.11 |
| ray_laptop | I wish there was a way to invert the sense of git bisect good/bad -- I have to stop and think beforehand if I'm looking for a bug fix instead of a regression (what's the point of software if I still have to think?) | 17:14.44 |
| chrisl | I've said the same thing - can be very confusing! | 17:15.16 |
| nicoo | ray_laptop: Make a feature request :) | 17:15.39 |
| chrisl | nicoo: just guessing, but I think your third party libs archive might need updating. | 17:15.47 |
| ray_laptop | I guess I could do aliases for "bisect good" and "bisect bad" | 17:15.51 |
| | but an option to git start would be nicer (IMHO) | 17:16.25 |
| chrisl | Yes, that would be good. Might be worth asking | 17:16.47 |
| Robin_Watts | nicoo: Yes, chrisl is correct. | 17:16.51 |
| | see http://mupdf.com/download/mupdf-thirdparty.zip | 17:17.05 |
| nicoo | chrisl: Since I didn't download the archive, I assume it uses the system's version | 17:17.11 |
| | I'll update these | 17:17.21 |
| Robin_Watts | nicoo: Messing with your systems shared libs leads to dependency hell. | 17:18.02 |
| nicoo | Robin_Watts: cave fix-linkage is here for that :) | 17:18.25 |
| ray_laptop | we hate sharing system libraries ! They're usually wrong and cause hard to track problems | 17:18.25 |
| Robin_Watts | Easier to use our supplied thirdparty.zip and just build mupdf with the static libs (that's what the makefile does) | 17:18.35 |
| | And if you find a bug, we'll tell you to retest with it built in that way before we believe you :) | 17:18.59 |
| nicoo | ray_laptop: Yes, but having each and every application bring its own version of every bleeding dependency isn't much better | 17:19.11 |
| ray_laptop | I've lobbied for dropping support for shared libs for ghostscript for years | 17:19.21 |
| nicoo | I suppose I can begin with trying the thirdparty archive | 17:21.04 |
| Robin_Watts | nicoo: If you want a version that uses the shared libs on your system, then get it from your systems maintainers, who can package and support it. | 17:24.01 |
| chrisl | ray_laptop: on the one hand I agree with you (shared libs) - on the other, the distributions would keep doing it anyway, and we'd still catch the fallout from it, so in practice, it doesn't really matter. | 17:24.18 |
| Robin_Watts | If you want us to support it, then build it in the way we specify :) | 17:24.32 |
| chrisl | Which is what we say now - doesn't stop people b*tching at us, though | 17:25.13 |
| henrys | a public statement hanging off the ghostscript page saying build it with static libraries and report bugs or build it with shared libs and report to your distribution. The latter is untested software, we are not surprised or need to know it fails we expect it to. | 17:27.52 |
| Robin_Watts | henrys: Yes. I wonder about a 'bug reporting wizard' thing. | 17:28.53 |
| ray_laptop | henrys: we ought to burp out that warning whenever anybody does a 'make' with any SHARE_***=1 | 17:29.03 |
| nicoo | Robin_Watts: Problem is that the Exherbo's version doesn't provides mudraw, so I wanted to add an option to get it | 17:29.28 |
| ray_laptop | a nice LONG message with ******************* bracketting it | 17:29.30 |
| chrisl | ray_laptop: I thought about that (and even started it) but the end users that report stuff would never see them, and the maintainers would ignore them, so I dropped it | 17:29.47 |
| nicoo | Ok, I built mupdf with static libs; how do I build mudraw, now ? | 17:30.04 |
| Robin_Watts | ray_laptop: Which will immediately scroll off the screen, due to all the other long messages with ******** bracketing them that people ignore :) | 17:30.08 |
| | nicoo: You did 'make' ? | 17:30.26 |
| henrys | I was just thinking a web page with a link so we can avoid these conversations but maybe it will just create more discussion. | 17:30.29 |
| Robin_Watts | Then you've built it. | 17:30.32 |
| chrisl | Robin_Watts: the important warnings, I put right at the end the configure output. | 17:30.48 |
| ray_laptop | Robin_Watts: we could hang the build with a 'read' to make the builder have to respond in order to complete the build ;-) | 17:30.56 |
| nicoo | Robin_Watts: My bad; mistyped when running find | 17:31.30 |
| chrisl | henrys: could we add stuff to the web page *and* the bugzilla "new bug" form? | 17:31.33 |
| nicoo | Thanks | 17:31.34 |
| Robin_Watts | ray_laptop: The packagers would just remove it :( | 17:31.34 |
| | chrisl: I was thinking of the 'new bug' form (or a page that leads to the new bug form) | 17:32.24 |
| henrys | chrisl:fine by me... | 17:32.55 |
| ray_laptop | is there a way to tell if we are running with a shared lib ? | 17:32.57 |
| henrys | I don't think we can change the ways of the distros - we just want to get them to filter the problems right? | 17:33.51 |
| chrisl | Robin_Watts: Yeh, but not as complex as a "wizard", just something saying: "If you're using a 'packaged' Ghostscript, your first port of call should be your distribution package maintainer" | 17:33.59 |
| ray_laptop | yeah, and then if a bug comes from a distro maintainer, we insist they test with a non-shared lib build | 17:34.50 |
| henrys | chrisl:do you want to follow up on this? You have all the needed permissions right? | 17:35.22 |
| Robin_Watts | chrisl: I was pondering having a menu of possible options for "Where did you get the version of ghostscript that you are running?" | 17:35.39 |
| ray_laptop | chrisl: can we at least make the configure default to non-shared and require --enable-shared-*** for each and every lib that they want to share ? | 17:36.18 |
| chrisl | henrys: I don't think I do for bugzilla, but I'll talk to marcosw_ about it | 17:36.28 |
| Robin_Watts | "A binary distribution from ghostscript.com", "A binary distribution from somewhere else", "Built from source with the included libraries", "Built from source with system libraries", "Packaged with my distribution" | 17:36.54 |
| chrisl | ray_laptop: at the moment, it does default to non-shared - you have to explicitly delete/rename the third party lib directories to make it happen - I'm willing to require command line options, too, though. | 17:37.25 |
| Robin_Watts | And for most of those we can refuse to open the bug and give a helpful piece of advice telling them to retest with the proper version or to report to their packagers as appropriate. | 17:37.46 |
| chrisl | Robin_Watts: that's probably a good idea - if we can do it easily in bugzilla..... | 17:38.17 |
| | henrys Robin_Watts: we should probably create a bug, so this doesn't get forgotten | 17:40.30 |
| ray_laptop | bugzilla is rather yucky code, iirc | 17:40.39 |
| chrisl | I think adding custom menus is just a configuration option, but I don't know about doing "clever" stuff based on the selection in the menu. | 17:41.32 |
| Robin_Watts | That's why I wondered about having a 'bug reporting wizard' (i.e. a screen you go through before getting to bugzilla) | 17:42.47 |
| chrisl | Although, past experience says people will just select whatever one lets them get to the next page they wanted :-( | 17:44.28 |
| ray_laptop | hurray ! my laptop stayed up long enough to make it through 6 steps of git bisect testing to find cust 532's problem (I think -- now to test with their code) | 17:45.21 |
| henrys | chrisl:I just thought an announcement would let us simply point to something and avoid the tiring discussion, I don't think we're going to set up anything that results in 0 interaction. | 17:46.28 |
| chrisl | henrys: I'll write something up for the web page next week, that's easy enough. We can consider further options at our leisure. | 17:47.53 |
| henrys | okay great | 17:48.07 |
| chrisl | thinks: how can I implement an "I'm not an idiot" button in html....... ;-) | 17:48.42 |
| henrys | if you figure it out get a patent | 17:49.22 |
| | bbia few minutes | 17:49.41 |
| ray_laptop | chrisl: just have a button that says "If you know exactly what you are doing, click here." -- only misguided idiots will click it ;-) | 17:52.24 |
| chrisl | ray_laptop: probably already patented] | 17:59.52 |
| mvrhel | ray_laptop: question for you | 18:06.14 |
| | should the warning about the limit reached for the number of spot colors be displayed only with a debug build? | 18:06.38 |
| tannerwatson | just curious, but I notice a significant memory use increase when converting multi page PDFs to TIFF. Is this normal? | 18:07.49 |
| | also, is it possible to call gsapi_init_with_args multiple times with the same GS instance (from gsapi_new_instance)?? | 18:09.36 |
| Robin_Watts | http://bugs.ghostscript.com/enter_bug2.cgi | 18:17.23 |
| | Ahem: http://bugs.ghostscript.com/enter_bug2.cgi?product=Ghostscript | 18:18.44 |
| mvrhel | I think I will just use dlprintf1 which is also used to print the names of the spot colors in tiffsep | 18:19.05 |
| chrisl | Robin_Watts: looks okay - but will the great unwashed know what "provenance" means? | 18:20.09 |
| tannerwatson | Robin_Watts, I'll submit a bug report | 18:20.38 |
| | Robin_Watts, thanks | 18:20.45 |
| Robin_Watts | chrisl: That's why it says "-- Where did you get the software you are reporting the bug for? --" | 18:20.47 |
| | tannerwatson: Sorry, that wasn't aimed at you! | 18:20.57 |
| | We are discussing some changes to our bug tracker, and that's a mockup. | 18:21.17 |
| tannerwatson | Robin_Watts: oh, ok. sorry | 18:21.18 |
| | Robin_Watts, is it acceptable to call gsapi_init_with_args multiple times with the same instance of GS created with gsapi_new_instance?? | 18:22.06 |
| chrisl | tannerwatson: the memory use is entirely dependent on the PDFs in question - but in general, a multipage PDF will require us to hold more stuff in memory than a single page file would. | 18:22.23 |
| Robin_Watts | tannerwatson: I don't know, sorry. | 18:23.00 |
| tannerwatson | chrisl, yeah i understand thanks :) | 18:23.29 |
| chrisl | tannerwatson: you'd be better aiming your API question at ray_laptop | 18:23.41 |
| | tannerwatson: also be aware that certain constructs in PDF can cause a big increase in memory use and CPU time - especially transparency. | 18:24.40 |
| tannerwatson | chrisl, thanks. Right now we are converting PDFs that were created from scanning documents. Nothing special has been applied the PDFs. When we try to convert 300+ 200KB memory consumption reaches above 2GB......it may be our implementation though | 18:27.14 |
| | chrisl, we are making the calls through C#........so that may be part of the problem | 18:27.39 |
| mvrhel | yikes! | 18:27.51 |
| tannerwatson | :P | 18:29.06 |
| | its probably just me..... | 18:29.17 |
| chrisl | tannerwatson: yeh, that doesn't sound right - this is using gsapi_init_with_args() multiple times on the same context? | 18:29.27 |
| marcosw_ | chrisl and Robin_Watts: I didn't think we had that many bugs that ended up being traceable to shared libraries, but if we really, really don't want people running ghostscript/mu with shared libraries isn't it straightforward to just call system("file *argv[0]") and refuse to run if the executable isn't statically linked? | 18:33.23 |
| Robin_Watts | marcosw_: Ew. Ew. Ew. | 18:34.08 |
| chrisl | marcosw_: to be honest, we don't get than many bugs, it's mainly people on here. Besides, you *can't* statically link glibc these days, so there will always be some dynamic linking going on. | 18:34.51 |
| Robin_Watts | People are welcome to run it like that. They just aren't welcome to expect support. | 18:34.57 |
| marcosw_ | so anyone who answers "No shared libraries" on http://bugs.ghostscript.com/enter_bug2.cgi?product=Ghostscript is lying? | 18:36.18 |
| chrisl | Well, sort of, I suppose...... | 18:36.55 |
| Robin_Watts | OK, updated version: http://bugs.ghostscript.com/enter_bug2.cgi?product=Ghostscript | 18:55.56 |
| | henrys: ping | 19:06.05 |
| | (For the logs, then) henrys: You said the HPGL filling style thing was going to be required after all, so I looked into it a bit on the plane. | 19:07.52 |
| | All my tests indicate that the code is doing what my understanding of the issue says I should be doing. | 19:08.22 |
| | But testing a clusterpush shows that something clearly isn't right. | 19:08.38 |
| | So either my understanding of the issue is broken, or the code is calling it in a way it shouldn't, or there is some case that my testing isn't showing up. | 19:09.54 |
| | Looking at the output from the bmpcmp, (and thinking back to something you said before) it seems to me like the current path is getting lots of moveto's added to it. | 19:11.00 |
| | whenever the current point is moved, you add a moveto to the path, I bet. | 19:11.16 |
| | If you then 'fill' that path, unsuprisingly bad things happen. | 19:11.44 |
| chrisl | Robin_Watts: a slight concern with the bugzilla change is that Average Joe (even those who build GS) isn't going to know what "shared libraries" are, so we just end up increasing noise on here. | 19:13.04 |
| Robin_Watts | chrisl: I'm amenable to changing the descriptive wording on the page. | 19:13.36 |
| | I think most people will assume that they don't have shared libraries if they don't know what they are. | 19:15.18 |
| | (Hence that option being earlier in the list) | 19:15.32 |
| chrisl | Robin_Watts: that's it, though, I'm not sure - perhaps just something like "From ghostscript.com", "from distribution", "from source", "from source 'custom' build". If we make it too verbose, no one will read it at all. | 19:15.43 |
| Robin_Watts | Well, we have to allow for ghostscript.com/mupdf.com/git :) | 19:16.15 |
| | And they have to read it - because it will refuse to create the bug until they've selected one :) | 19:16.37 |
| chrisl | Like all those license agreements that won't dismiss until you've "read" them? | 19:17.05 |
| Robin_Watts | chrisl: That's different - there there is just an 'accept' button. | 19:17.28 |
| chrisl | My suspicion is that people who don't know (or who are sufficiently bloody minded) will just keep trying menu options until it lets them create a bug | 19:18.29 |
| Robin_Watts | If people are going to be put off by having to spend 5 seconds picking a sensible option off a menu, then I for one don't want to read a bug they are going to create. | 19:18.50 |
| Robin_Watts | foods. | 19:19.32 |
| chrisl | No, but it won't *stop* people who just keep trying every option until they get their bug | 19:19.38 |
| | TBH, I'd be quite happy to try it as it stands - it's not like it commits us to anything other than trying it. Maybe discuss it on Tuesday. | 19:20.15 |
| Robin_Watts | chrisl: Right. but they will hopefully be marginally more informed by the process. Nothing will stop idiots, right? | 19:20.32 |
| mvrhel | marcos_: never heard from you about tiffsep testing. | 19:20.37 |
| | I have the files running correctly from the customer | 19:20.51 |
| | but need to do some cluster testing now | 19:21.07 |
| chrisl | Robin_Watts: not in my experience, no - idiots are more persistent than zombies :-( | 19:21.12 |
| mvrhel | and looking at piles of output.... | 19:21.17 |
| chrisl | finished for the day..... | 19:21.31 |
| mvrhel | bye chrisl | 19:21.37 |
| | oops that was supposed to be marcosw_ | 19:23.10 |
| marcosw_ | mvrhel: sorry, but I never received an email from you. When did you send it and that was the subject? | 19:25.15 |
| mvrhel | marcosw_: oh you were waiting for an email from me. | 19:25.38 |
| | we had a discussion on IRC I thought | 19:25.47 |
| | which ended with you I thought you were to send me an email | 19:26.19 |
| marcosw_ | sorry, I only saw the part where you said you were going to send me an email. I didn't realize there was enough discussion on irc to let me know what you wanted. | 19:26.21 |
| mvrhel | ok. fair enough. let me send you an email now | 19:26.42 |
| marcosw_ | was this the relevant sentence?: wonder how hard it would be to have marcos temporarily add in tiffsep into the clusterpush a comparison of the composite output file with also the capability for bmpcmp | 19:27.16 |
| mvrhel | yes. but let me write the email so everything is crystal clear and there is no wasted work | 19:27.43 |
| marcosw_ | thanks. | 19:28.37 |
| ppd | hi. maybe somebody remembers me. I am the ubuntu kyocera guy. my kyocera printers refused to print with the ps output from ghostscript but worked with the poppler ps. So you guys investigated this problem by sending me a bunch of files to try and eventually came to a solution. ((https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/951627). The problem seemed to have gone, but recently I tried printing a few documents with pict | 19:34.51 |
| | ures included. It was a disaster. the printer tages ages to process the document... again:poppler postscript works. what can I do to investigate this problem further? | 19:34.53 |
| ray_laptop | ppd: are you using pswrite or ps2write ? | 19:42.58 |
| ppd | ray_laptop: I have no idea. I just print with the standard cups configuration and it does not work. Then I convert the same pdf with pdftops from poppler and send it via netcat to the printer. this works | 19:46.06 |
| mvrhel | marcosw_ ok email sent. | 19:49.15 |
| | Robin_Watts: you may have some thoughts on this testing also, so I cc'd tech | 19:49.30 |
| | lunch time | 19:56.17 |
| chrisl_r61 | ppd: the guy that worked with you on that won't be online until tomorrow morning (UK time). | 20:02.24 |
| | ppd: but frankly, there's not likely to be much we can do - the ps2write image output is just a "normal" Postscript image - not significantly different to the pdftops image output. | 20:03.42 |
| marcosw_ | mvrhel: Ithx. | 20:05.41 |
| ppd | chrisl_r61: I thought so too. but still printing with the poppler backend results in waaaaaaaay faster printing. the pdf2ps command also takes much longer to process than pdftops and produces a bigger file | 20:07.19 |
| | speaking of a libreoffice pdf with some text and one pretty small header picture | 20:08.18 |
| chrisl_r61 | ppd: are you using up to date cups package? | 20:08.30 |
| ppd | latest ubuntu precise. that is the 1.5.2 release | 20:08.56 |
| ray_laptop | ppd: you want to be using pdf2ps2 (script that uses ps2write). | 20:10.10 |
| chrisl_r61 | I can't remember what version Till was up to - we had to update cups, ghostscript and one of the cups filters packages. | 20:10.23 |
| ppd | ray_laptop: and if the printer doesn't choke on this output, what does that tell me then? | 20:11.26 |
| chrisl_r61 | ppd: the reason the file from GS is bigger is because we had to disable a load of compression stuff because Brother and HP printers failed with certain compression filters - we figured it safer to disable, than have loads of special cases. | 20:11.39 |
| ray_laptop | ppd: pswrite (pdf2ps) generates Level 1 PS and effectively renders images to the resolution of the printer whereas ps2write embeds the "original" image from the input PDF | 20:11.44 |
| chrisl_r61 | ray_laptop: the pdf2ps2 output will fail on his printer because it has a bug in "bind" which causes it to freeze | 20:12.21 |
| ppd | ah yes. that was the first problem | 20:12.44 |
| | now text output is ok | 20:12.49 |
| ray_laptop | then get a f/w update from kyocera (it's their own PS, not ours) | 20:12.58 |
| chrisl_r61 | <whines> but the poppler output works </whines> | 20:13.50 |
| ray_laptop | ppd: but, frankly if the printer can't handle valid PS Level 2 (current standard is Level 3) we aren't very interested | 20:13.53 |
| | and if poppler output happens to work on that file, then use it, but don't expect it to be very correct in general | 20:14.29 |
| | we consider pswrite (Level 1.5 PS) output deprecated and don't support it | 20:15.12 |
| chrisl_r61 | ray_laptop: the problem is CUPS has switched from poppler's pdftops to our ps2write output, so people see their printer used to work, now it doesn't :-( | 20:15.19 |
| ray_laptop | chrisl: and the reason they switched is that now GS is faster than poppler for many cases, and more accurate. | 20:16.04 |
| | sounds lto me like ppd has a work around so should use it for this (broken) printer | 20:16.36 |
| chrisl_r61 | Yes, cups now has solutions for several of these buggy printers, but this is a different problem he's asking about now | 20:17.14 |
| ray_laptop | I'm going to suggest (at the staff meeting) that we remove pswrite from the default set of devices | 20:17.17 |
| chrisl_r61 | ray_laptop: ps2write can't emit EPS yet | 20:17.37 |
| ray_laptop | chrisl: so ? | 20:17.51 |
| ppd | I didn't mean to waste your time... my work around is of course not usable for the average user in the office and thus not applicable... | 20:17.55 |
| ray_laptop | chrisl: we do DSC compliant PS Level 2, however | 20:18.06 |
| chrisl_r61 | ray_laptop: people do still create EPS files, so we really need ps2write to do that before we remove pswrite completely - I'd have thought | 20:18.51 |
| ray_laptop | chrisl: IMHO we have lots of better things to do than to develop work around for buggy printers | 20:19.11 |
| chrisl_r61 | ray_laptop: I'd agree, on the whole..... | 20:20.28 |
| ray_laptop | chrisl: particularly for free users | 20:20.32 |
| chrisl_r61 | ray_laptop: we tend to treat Ubuntu as a bit more than a free user...... | 20:21.08 |
| ray_laptop | ppd: Is this a current kyocera printer (that has a bug in 'bind' that makes ps2 output hang) or some ancient test engine ? | 20:21.17 |
| ppd | ray_laptop: it is a fs-1320d and a fs-c1020mfp. my recent testing was only on fs-1320 though | 20:22.06 |
| ray_laptop | because we know that Kyocera is generally quite responsive with f/w fixes for current products | 20:22.15 |
| chrisl_r61 | ppd: about the only thing I can think of that might be different between our PS and poppler's would be the color space or resolution of the images - frankly, neither should make a *huge* difference. | 20:22.25 |
| ray_laptop | chrisl; I'd have to see the PS, but if we are using pswrite, then I suspect that the image is very high (full printer) resolution having been upscaled by pswrite | 20:23.20 |
| chrisl_r61 | ray_laptop: it's ps2write | 20:23.47 |
| ray_laptop | and if the original PDF has transparency we KNOW that some files end up creating printer resolution images fromthe pages | 20:23.57 |
| ppd | the problem I descrive here happens with a mini image in a bill from a shop program | 20:24.28 |
| ray_laptop | particularly if it is that yucky Cairo PDF with gratuitous use of transparency (when it isn't needed) and full page bounding boxes | 20:24.50 |
| ppd | so it is not even a full image covering a whole page | 20:24.53 |
| chrisl_r61 | ppd: but how big is the *original* image file, though? | 20:25.08 |
| | ray_laptop: I think libreoffice creates it's own PDF, doesn't go through cairo | 20:25.37 |
| ray_laptop | ppd: the best thing to do is to open a bug so you can attach the PS file we generate, the PS file from poppler AND the original PDF | 20:25.53 |
| ppd | 10,8 kB | 20:26.05 |
| chrisl_r61 | ppd: okay, so unless, as ray_laptop says, there's transparency in there, there is no reason for the image to make a difference like you see. | 20:26.55 |
| ray_laptop | ppd: unless you know how to examine the PDF and PS files to see what the 'image' parameters are (Width Height Filter, etc) | 20:26.56 |
| chrisl_r61 | ppd: I agree with ray_laptop, if you create a bug and attach the two PS jobs, at the very least we can tell you *exactly* what to tell Kyocera. | 20:27.48 |
| ppd | chrisl: do I need to create the ps output with cups involved or is pdf2ps etc. sufficient? | 20:28.43 |
| ray_laptop | ppd: as long as the output from pdf2ps runs slow (as with cups) that and the pdftops (from poppler) that runs fast AND the original PDF, should suffice | 20:29.44 |
| henrys | Robin_Watts:so the reverted commit is the latest and what I should debug with if I want to study it in the debuggser? | 20:29.57 |
| chrisl_r61 | ppd: it would be better if you went through the cups workflow for the Ghostsrcript output, given the workarounds we had to include, doing pdftops for the poppler output should be fine. | 20:30.05 |
| | ray_laptop: <again> the pdf2ps2 output won't run directly on his printer because of the bind bug | 20:30.38 |
| ray_laptop | defers to chrisl since he's had more experience struggling with what cups does | 20:30.39 |
| ppd | hehe. I will do so and create a bug report | 20:31.35 |
| mvrhel | got distracted writing emails. | 20:32.49 |
| | now it is lunch time | 20:32.52 |
| chrisl_r61 | ppd: don't hold your breath, though, at some point you're going to have to report their broken interpreter to Kyocera, and stop reporting our *valid* Postscript to us! | 20:34.11 |
| ray_laptop | chrisl: How can I generate a PS file that hangs Kyocera ? | 20:35.45 |
| | I'll submit it to them :-) | 20:36.25 |
| chrisl_r61 | ray_laptop: on this particular printer, it didn't even get through the ps2write prologue | 20:36.32 |
| ppd | I understand your point. I'm not the asshole user that expects everything to work magically when the hardware manufacturers glue crap together and call it a printer. I just thought it would be in the interest of many that kyocera printers worked with ghostscript | 20:36.44 |
| chrisl_r61 | ppd: sure, and that's one reason we worked on it before with you, but at some point...... | 20:37.24 |
| | ray_laptop: I couldn't get the ps2write Postscript to fail in the simulator. | 20:38.39 |
| | ppd: how much difference in size is there between the two PS files (from GS and poppler)? | 20:41.10 |
| ppd | chrisl: true. does mac os's cups use ghostscript by default? it's hard to believe that kyocera effectively abandons this platform | 20:41.21 |
| chrisl_r61 | ppd: no, Apple does something else - not sure what. | 20:41.54 |
| ppd | chrisl: 1,1MB versus 807,5kB | 20:42.05 |
| chrisl_r61 | Okay, so we're similar ball park figure, then. It's probably not spurious PDF transparency bloating the PS output. | 20:43.08 |
| ppd | chrisl: something is in there that makes the printer go crazy and process and process and.... | 20:44.14 |
| chrisl_r61 | Well, it really is *very* straightforward Postscript Level 2 - it doesn't even stretch the limits of Level 2. | 20:45.04 |
| | ppd: Does adding and removing *just* the image really make all the difference? | 20:45.45 |
| ppd | chrisl:hm. you know what, I didn't even try with this specific document... what a pity I don't have this printer here at home... | 20:46.56 |
| chrisl_r61 | ppd: well, as we said, stick up a bug on our bug tracker with the PDF, and the PS examples, and we'll have a look - you can assign it to me, or Ken (who worked with you before). | 20:49.41 |
| ppd | but I'm pretty sure it had no problems with pure text output, that was fixed. I tried one full-page image a few days ago. It eventually came out after many many minutes of the printer displaying "procesing". | 20:49.54 |
| chrisl_r61 | ppd: the problem is, as ray_laptop mentioned, cairo produces really cr*p PDFs in many cases, and something as simple as adding an image could be the thing that tips it - I didn't think libreoffice used cairo, but I could be wrong. | 20:51.35 |
| ppd | chrisl: I'll just check the same document without the picture. then the bug report can be more accurate | 20:51.52 |
| chrisl_r61 | ppd: the other thing you can try is to use the CUPS-PDF backend, instead of exporting directly from libreoffice. The CUPS-PDF back end doesn't use cairo. | 20:53.12 |
| ppd | chrisl: hehe. crappy pdfs, crappy printer firmware... and you are stuck in between. I dont envy you | 20:53.44 |
| | chrisl: I'll just try everything you mentioned when I get my hands on this printer again. hopefully this will enlighten us... | 20:54.54 |
| chrisl_r61 | ppd: well, we have crappy bits and pieces, too, which when time is available we look to improve. Cairo's PDF has improved a lot, but the improvements are in a bleeding edge version, not in many distros yet. | 20:55.07 |
| ppd | but as I understand, if kyocera fixed their ps interpreter to completely support the standard we wouldn't be here talking. am I right? because ghostscript doesn't use any non-standard markup?! | 20:57.54 |
| chrisl_r61 | ppd: PS isn't a markup language, but yes, essentially that's the case. | 20:58.29 |
| | ppd: after your problem and the Brother problems, we actually tested our output on four or five PS interpreters from entirely different sources, and all worked fine, too. | 20:59.47 |
| ppd | chrisl: nice. and the windows driver gets all those workarounds from the manufacturer pre-packaged... sometimes I feel so tired ;-) | 21:00.31 |
| chrisl_r61 | ppd: yeh, it's a bit of a world of pain at times...... | 21:02.15 |
| | ppd: I'll keep an eye out for the bug.... | 21:04.07 |
| | ....but, for the second time today, I'm signing off, for the day | 21:04.18 |
| ppd | chrisl: thanks a lot for your patience | 21:04.37 |
| Robin_Watts | henrys: reverted commit? | 21:50.51 |
| | All I did to run my latest test was to force hpgl mode on: | 21:52.22 |
| | In gs/base/gxistate.h: | 21:52.41 |
| | @@ -295,7 +295,7 @@ struct gs_imager_state_s { | 21:52.50 |
| | /* Initialization for gs_imager_state */ | 21:52.52 |
| | #define gs_imager_state_initial(scale, is_gstate)\ | 21:52.53 |
| | - is_gstate, 0, 0, { gx_line_params_initial }, 0,\ | 21:52.55 |
| | + is_gstate, 0, 0, { gx_line_params_initial }, 1,\ | 21:52.56 |
| | { (float)(scale), 0.0, 0.0, (float)(-(scale)), 0.0, 0.0 },\ | 21:52.58 |
| | false, {0, 0}, {0, 0}, false, \ | 21:52.59 |
| | lop_default, gx_max_color_value, BLEND_MODE_Compatible,\ | 21:53.01 |
| | And then run a: git cluster pcl lowres | 21:53.02 |
| | That gives the bmpcmp that's current. | 21:53.21 |
| | mvrhel: ping | 21:56.03 |
| mvrhel | just heading out the door.... | 21:56.42 |
| | you are lucky I heard the ping | 21:56.47 |
| Robin_Watts | ok. I'm just going to bed (jeglag). | 21:56.54 |
| mvrhel | good night! | 21:57.02 |
| Robin_Watts | I'll burble here for the logs. | 21:57.03 |
| mvrhel | is it about the email that I sent? | 21:57.17 |
| Robin_Watts | yes. | 21:57.22 |
| mvrhel | ok great | 21:57.26 |
| Robin_Watts | AIUI testing tiffs is a non-starter in the cluster cos of the need to seek within the files as they are written (cluster works by piping, so seeking won't work). | 21:58.08 |
| | So we can't test tiffsep directly. | 21:58.23 |
| | But testing psdcmyk would be equally good, right? | 21:58.44 |
| mvrhel | yes. we are currently testing those. what I want to do is see the diff though | 22:00.03 |
| | Robin_Watts: but only if they are really different | 22:00.39 |
| Robin_Watts | Why can't I just extend bmpcmp to read psdcmyk files too ? | 22:00.49 |
| mvrhel | oh. that would be great | 22:00.59 |
| Robin_Watts | bmpcmp can cope with cmyk files. | 22:01.08 |
| mvrhel | well psdcmyk is a little more complex | 22:01.19 |
| | in that it has cmyk+ spots | 22:01.27 |
| | and it includes information in the file on how to map the spots to cmyk | 22:01.45 |
| Robin_Watts | Right. So I'd either need to only look at cmyk or I'd need to extend it. | 22:01.53 |
| mvrhel | you can see this in the pdscmyk device information | 22:02.06 |
| Robin_Watts | Are the specs for the file format somewhere? | 22:02.19 |
| mvrhel | did you write bmpcmp? | 22:02.20 |
| | yes. I will email you the specs | 22:02.29 |
| Robin_Watts | I did. | 22:02.31 |
| mvrhel | there is no compression and the data is all planar | 22:02.41 |
| Robin_Watts | Fab. | 22:03.01 |
| mvrhel | there are a lot of options in psdcmyk and we only use a tiny subset of these in our files | 22:03.12 |
| | let me put together something for you to look at in the morning. this is a great idea | 22:03.30 |
| | I will try to distill what you may need | 22:03.44 |
| Robin_Watts | The other thought I had... | 22:03.49 |
| | For the plank stuff we tested plank vs ppm. | 22:04.26 |
| mvrhel | yes | 22:04.34 |
| Robin_Watts | (so planar vs non-planar) | 22:04.35 |
| | OK. Ignore that. | 22:04.54 |
| | tiffs fail as I said before because of the need to seek within the files. | 22:05.33 |
| mvrhel | ok. I like your idea of having bmpcmp work on psdcmyk output. let me do a little work on this for you for the morning | 22:05.52 |
| Robin_Watts | but if we are just md5ing the data (as the cluster does), we don't care about the seeking. | 22:06.07 |
| | because that's just to go back and write the indexes - and the indexes will be the same if the data is the same, and different if it's different. | 22:06.37 |
| mvrhel | right. md5 is great for psdcmyk also and plus the psdcmyk includes all the seps, vs. the tiffsep composite is not the seps | 22:06.45 |
| | so psdcmyk is actually good for us to test. | 22:07.01 |
| Robin_Watts | So psdcmyk is a better solution then? | 22:07.02 |
| mvrhel | yes | 22:07.06 |
| Robin_Watts | OK. So I'll look at that tomorrow then. | 22:07.11 |
| mvrhel | if we add bmpcmp to it it will be great | 22:07.19 |
| | the devices are very similar it is just that psdcmyk can pack all the information into one file | 22:07.41 |
| Robin_Watts | I could maybe just make bmpcmp run 4 components at a time. | 22:07.57 |
| | if the data is planar it would lend itself to that. | 22:08.11 |
| mvrhel | N components. and yes the data is planar | 22:08.27 |
| Robin_Watts | (well, 4 components, then 1 at a time for the spots maybe) | 22:08.31 |
| mvrhel | ok well, lets see if we can actually use the mapping information in the psdcmyk to reduce the number of images that we need to visually look at | 22:09.17 |
| | i.e. if a file has 14 colors, having to look at 10 differences is harder than just 1 | 22:09.44 |
| henrys | Robin_Watts:sorry I thought you had reverted the code. | 22:09.47 |
| mvrhel | 11 differences I mean | 22:10.10 |
| | vs 1 | 22:10.12 |
| | anyway, have to head out for a bit | 22:10.37 |
| | bbiaw | 22:10.39 |
| Robin_Watts | mvrhel: Right, but we want to look for the differences in the raw data, not just differences in the composite, right? | 22:10.46 |
| henrys | but we have been through this before, and we found a simple example "the triangle" that seemed to send you back to the drawing board, were I younger man I'd tell you the details. | 22:10.58 |
| | I'm sure I can recover that example though. | 22:11.16 |
| Robin_Watts | henrys: If you could, that would be great. | 22:11.27 |
| henrys | will do. | 22:11.47 |
| Robin_Watts | My memory is that we'd got further than this, but that there was something else wrong, but I couldn't reproduce it in a small example. | 22:12.19 |
| henrys | a lesson fro me to always update the bug. | 22:12.23 |
| | s/fro/for | 22:12.41 |
| Robin_Watts | Ah, we had a simple HPGL file that drew a large vertical line, then a triangle. | 22:13.17 |
| henrys | oh yes we must have gotten further you've only got 18 pages of diffs, the previous test was most jobs broken. | 22:13.56 |
| Robin_Watts | This is still most jobs broken; this was only lowres pcl, and bmpcmp only does the first 1000. | 22:16.31 |
| henrys | oh okay | 22:17.12 |
| | stops at 674 though, but you got a report with most jobs reported broken? right? | 22:18.46 |
| Robin_Watts | 3xxx out of 4xxx failed. | 22:18.59 |
| | henrys: http://bugs.ghostscript.com/enter_bug2.cgi?product=Ghostscript in case you didn't see it earlier. | 22:19.40 |
| henrys | yes I did look at it, thought we could discuss it tuesday as someone else suggested. | 22:20.24 |
| Robin_Watts | oh, ok, I missed that. | 22:20.34 |
| henrys | so let me come up with a simple fill that fails and see what's going on here. Like I said it would be quite challenging to remove superflous moveto's - in hindsight it was a poor design decision to track the current cursor with the path code. | 22:22.37 |
| Robin_Watts | That may be a showstopper for this approach. | 22:23.28 |
| | We are specifically giving: moveto moveto a meaning w.r.t filling. | 22:24.05 |
| | So if we have a superfluous prefix of movetos in a path, we're going to get confused :( | 22:24.37 |
| henrys | understood let me look at it a bit. | 22:25.09 |
| | in practice though I don't expect many to come up when we are filling - based on these test results it looks as though your new code has had some effect on stroke mode, but I'll have to confirm that. | 22:28.05 |
| Robin_Watts | yes, I think you may be right. But I don't see how. I will try a test for that tomorrow too. | 22:29.26 |
| henrys | I should have a simple test for you by the time you get in tomorrow. Have you recovered from your travels? | 22:30.10 |
| Robin_Watts | I'm falling asleep at the keyboard now, but it was only a 5 hour time difference, so it's not as bad as other trips. | 22:30.51 |
| | henrys: Yes, I've broken stroking. | 22:39.59 |
| | I'll look into that tomorrow, and then retry the bmpcmp. | 22:40.22 |
| | That explains a lot of the diffs. | 22:40.42 |
| | bedtime. night all. | 22:40.50 |
| | Forward 1 day (to 2012/04/06)>>> | |
IRC Logs