| | <<<Back 1 day (to 2015/02/23) | 20150224 |
| Robin_Watts | mvrhel_laptop: hi | 00:09.48 |
| | I've had to look into the acrobat clipping rectangle thing before. | 00:10.53 |
| | There may be an open bug about it. | 00:11.00 |
| | That file is a slighjt variant on it, because the path is a sequence of rectangles rather than just one. | 00:12.05 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=691008 | 00:15.24 |
| | I may look into it tomorrow. | 00:15.52 |
| rayjj | mvrhel_laptop: I'd like a review of the patch for bug 69584{0,1} if you have a moment. It definitely fixes those bugs. http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=68c3e3e3b316299aa0f0b2544638fcf39d080706 | 00:41.44 |
| | (I guess that's for the logs for mvrhell) :-/ | 00:43.23 |
| | the bugs are bug 695840 and bug 695841. The other (older) patch is still in work, but regressions on it are OK | 00:44.02 |
| pipitas | There is a typo in the documentation: '-DNOPAUSE' here: http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=gs/doc/Ps2pdf.htm;hb=HEAD#note_13 | 01:35.27 |
| rayjj | pipitas: sort of. It turns out that ghostscript (which processes these options / switches) treats -d and -D the same (also some others including -s and -S and -h and -?). See psi/imainarg.c | 01:56.22 |
| | pipitas: while it may mislead some that gs options are case independent (WHICH THEY ARE NOT -- as in -f vs. -F) it isn't strictly *wrong*. I'll leave fixing it to chrisl or someone else. | 01:58.03 |
| | pipitas: and thanks for pointing it out :-) | 01:58.20 |
| pipitas | rayjj: I always thought that case sensitiveness to be absolute, also applying to -s/-d | 02:23.12 |
| | gs -H however doesn't work :-) | 02:23.51 |
| rayjj | pipitas: it's all controlled by psi/imainarg.c -- in C code "switch / case" statements case is sensitive since 'h' and 'H' have different integer values. | 02:39.57 |
| | and there is no: case 'H': | 02:40.21 |
| | pipitas: and when you say "it doesn't work", it actually does in that it starts gs (ignoring the -H) and prompts: GS> | 02:41.50 |
| | pipitas: just as for any bogus options/switched | 02:42.19 |
| hyper_ch | good morning, I'm curious where I can find all possible settings for ghostscript. E.g. I'm looking now at -dPDFSETTINGS but the man page doesn't tell me what I can set there | 07:30.51 |
| | hi kens | 08:24.16 |
| kens | Morning | 08:24.27 |
| | You're either up early or very late ;-) | 08:24.37 |
| hyper_ch | early? late? it's 09:24 | 08:24.57 |
| | is there some page that lists all -dxxxxxxx settings? | 08:25.16 |
| kens | There's teh Ghostscritp documentation, but it doesn't list them, it explains each one individually, and groups them by category | 08:25.48 |
| | Also, some switches are only obeyed by some devcies | 08:26.02 |
| hyper_ch | I looked at the man pages but couldn't find it | 08:26.30 |
| kens | Not man pages,the documentation, hold on a second | 08:26.42 |
| | http://www.ghostscript.com/doc/9.15/Readme.htm | 08:26.58 |
| | Or in the Ghostscript source code tree in ghostpdl/gs/doc | 08:27.10 |
| | Most switches are defined ehre: | 08:27.36 |
| | http://www.ghostscript.com/doc/9.15/Use.htm | 08:27.36 |
| hyper_ch | thx | 08:27.49 |
| kens | And also here: | 08:27.50 |
| | http://www.ghostscript.com/doc/9.15/Ps2pdf.htm | 08:27.51 |
| hyper_ch | my document scanner has some big issues with that one document | 08:29.04 |
| kens | Odd, you would think it would be consistent, unless it does OCR as well ? | 08:29.27 |
| hyper_ch | scanner doesn't do OCR | 08:29.44 |
| | abbyy fine reader for linux does it | 08:29.52 |
| kens | THen I'mkind of surprised by inconsistent behaviour, since all it does is wrap an image up as PDF. | 08:30.10 |
| | You would expect that if it works once it would continue to work | 08:30.25 |
| hyper_ch | the other scanner - mfp - is slow and can't filter out white pages when scanning both sides | 08:30.27 |
| kens | BTW don't use -dPDFSETTINGS | 08:30.44 |
| hyper_ch | well, I let 18k pages throught the document scanner this far | 08:30.46 |
| | why not use it? | 08:30.54 |
| | I'm just testing out different file sizes with it | 08:31.03 |
| kens | It sets *lots* of parameters, far better to set them individually as required. People often don't understand that its doing a great deal more than they think it is. | 08:31.28 |
| hyper_ch | well, I only use gs right now to see if the scanner screwed up ;) | 08:32.07 |
| | how would you then optimize file size? | 08:32.19 |
| kens | In your case its probably not important, but I often get people complaining because ';the text isn't searchable any more' after they use -dPDFSETTINGS=/screen | 08:32.45 |
| | First thing to do is subsample images, the majority of msot file content is image data | 08:33.06 |
| hyper_ch | well, first I let it go through gs before doing ocr | 08:33.12 |
| kens | Get to the resolution you need and no more | 08:33.16 |
| hyper_ch | I have different resolutions set on the scanner | 08:33.32 |
| kens | After that, it depends totally on the content of the fikle. | 08:33.35 |
| hyper_ch | for different purposes | 08:33.43 |
| | when I notarize documents I can them in at 600dpi/color | 08:33.56 |
| | normal letters and documents I scan at 300dpi/bw | 08:34.07 |
| kens | I can't really recommend a single set for all purposes. | 08:34.13 |
| hyper_ch | or sometimes greyscale | 08:34.16 |
| | if you don't set -dPDFSETTINGS it will default to /default right? which is low resolution | 08:34.51 |
| kens | default is *NOT* low resolution | 08:35.00 |
| | default settings are 'leave unchanged' | 08:35.10 |
| hyper_ch | ok | 08:35.31 |
| | do you happen to use kde? | 08:36.54 |
| kens | Nope, I mostly use WIndows | 08:37.02 |
| hyper_ch | what pdf viewer do you use there? | 08:37.13 |
| kens | Acrobat, MuPDF, Ghostscript | 08:37.22 |
| | Acrobat because its the ultimate arbiter of 'correct behaviour' | 08:37.44 |
| hyper_ch | I think Acrobat is terribly slow at rendering pdfs on the screen | 08:37.55 |
| kens | sometimes, but its the one everyone compares against, so we have to conform | 08:38.17 |
| hyper_ch | on my vm I use now PDF XChange Editor | 08:38.20 |
| | my canon mfp makes much bigger pdfs than my - faulty - brother document scanner | 08:39.33 |
| kens | COuld be all sorts of reasons, compressionselection for one. | 08:39.54 |
| hyper_ch | kens: want a comparison? | 08:47.29 |
| kens | Not hugely, I'm trying to work on a problem | 08:47.47 |
| hyper_ch | :) | 08:47.59 |
| kens | thinks; coffee input required | 08:48.36 |
| hyper_ch | coffee | 09:08.18 |
| | you said the magic word | 09:08.21 |
| Robin_Watts | Morning tor8 | 10:09.23 |
| | so, can I commit the changes without the acrobat hack ? | 10:09.56 |
| tor8 | Robin_Watts: go ahead! | 10:10.21 |
| Robin_Watts | Ta. | 10:10.25 |
| tor8 | ah, we need to tell fred about using tabs and not leaving trailing whitespace everywhere... | 10:12.33 |
| Robin_Watts | tor8: random idea occurred to me while I was out running. | 13:05.09 |
| | malc was complaining that a huge amount of profile time was spent in strcmp yesterday - presumably name matching. | 13:05.32 |
| tor8 | Robin_Watts: he's running through a badly balanced page tree over and over | 13:06.12 |
| Robin_Watts | Picsel avoid strcmping by gathering the names used in PDF files into a fixed table. | 13:06.27 |
| | Every name is then represented by an int. | 13:06.37 |
| tor8 | ideal solution -- don't do that! i.e. don't pre-scan all pages for bounding information... | 13:06.48 |
| kens | Robin_Watts : looks like that customer with the million page PDF file is prepared to share :-( | 13:07.06 |
| | 300 MB PDF file..... | 13:07.15 |
| tor8 | a strcmp on an 8 byte string shouldn't be all that much different from an int compare | 13:07.19 |
| Robin_Watts | tor8: ooh, I'd say it would be. | 13:07.41 |
| tor8 | less than ideal solution -- cache a flattened page tree or just have a one-slot 'this is where we were last time' to speed up iterative uses | 13:08.05 |
| | but both of those need care when updating pdf_obj's when we're editing | 13:08.24 |
| | so as to invalidate them | 13:08.33 |
| Robin_Watts | mmm. | 13:08.44 |
| tor8 | Robin_Watts: in mujs I started sort of doing something like it | 13:08.56 |
| | with the string interning table | 13:09.02 |
| | we could intern all pdf_obj names | 13:09.09 |
| | and then just do pointer comparisons | 13:09.14 |
| Robin_Watts | Right. | 13:09.25 |
| tor8 | but then all strings used in the interface would have to be interned as well, and not just string literals | 13:09.40 |
| | which would sort of defeat the point | 13:09.47 |
| Robin_Watts | My idea was to have a table, like picsel of the (say) 256 most common strings. | 13:09.48 |
| | We'd have a pdf_name type that was a char *. | 13:10.10 |
| tor8 | we could have a table of all known strings, and use constant ints for those keys | 13:10.11 |
| Robin_Watts | but if the char * was 1...255 then it was a name index. | 13:10.23 |
| | otherwise it was a real pointer. | 13:10.29 |
| tor8 | ... and another pdf_name type that's an enum? | 13:10.40 |
| Robin_Watts | no. just 1 type. | 13:10.46 |
| tor8 | ick! | 13:10.50 |
| | pointer magic number overloading, not a fan | 13:11.10 |
| Robin_Watts | we'd have pdf_strcmp that knows to check for it being a enum. | 13:11.16 |
| tor8 | speaking of which, the fz_meta interface has the void* pointer being used as both input and output? | 13:11.24 |
| Robin_Watts | Yes. | 13:11.35 |
| tor8 | ick. don't like that. it's awkward. | 13:11.44 |
| Robin_Watts | depending on the meta operation. | 13:11.50 |
| tor8 | but I'll rework that later, when I add support for metadata querying to the other languages | 13:12.02 |
| | like XPS | 13:12.05 |
| Robin_Watts | ok. I reserve the right to fight you on splitting it to input and output :) | 13:12.32 |
| tor8 | or add a second fz_meta_info call that has string -> string lookups of author, title, etc | 13:12.36 |
| | I hate in-out parameters | 13:12.45 |
| | so we can schedule a fight later :) | 13:13.03 |
| Robin_Watts | fz_meta is supposed to be the simplest possible generic interface. | 13:13.06 |
| tor8 | it looks like the gestalt interface in old macosx | 13:13.18 |
| | s/macosx/mac os/ | 13:13.24 |
| | btw, I'm butchering the pdf_processor code | 13:13.42 |
| Robin_Watts | If you want to implement an fz_meta_info that builds on top of fz_meta and looks nicer for common cases, I wouldn't fight that. | 13:13.50 |
| | tor8: ok... | 13:13.54 |
| tor8 | hopefully I can separate the interpreter and the run processor a bit more | 13:13.59 |
| Robin_Watts | tor8: increased separation is always nice. | 13:14.19 |
| tor8 | put some more of the logic in the interpreter, and not pass the pdf_csi struct to the individual processors | 13:14.32 |
| Robin_Watts | as long as it doesn't hurt us in terms of performance. That section is kinda critical. | 13:14.37 |
| | Again, that would be nice. | 13:14.58 |
| | So, essentially, what I am proposing with the name stuff is that we'd have an opaque pdf_name type. | 13:15.42 |
| tor8 | having the processor extract arguments from the csi should be done at the interpreter level, but it means having separate function pointers with different prototypes for the different commands | 13:15.44 |
| | I don't see how a pdf_strcmp would help, you'd still need to know the literal string is one of the known 256 | 13:16.12 |
| Robin_Watts | and functions like pdf_drop_name, pdf_keep_name, pdf_name_to_string (to get a char *) etc. | 13:16.17 |
| tor8 | pdf_to_name already exists for the latter purpose | 13:16.38 |
| Robin_Watts | It means everywhere we have strcmp("Resources", ...) we'd have pdf_namecmp(PDF_Name_Resources, ...) | 13:17.08 |
| tor8 | pdf_namecmp(obj, PDF_NAME_XXX) with a set of predefined constants | 13:17.09 |
| Robin_Watts | right, | 13:17.18 |
| tor8 | and have two internal pdf_name types | 13:17.22 |
| Robin_Watts | no. Just 1 type. | 13:17.28 |
| | Internally we'd be relying on the fact that values 1...255 were special. | 13:17.48 |
| tor8 | no point, we already have enums for many internal types | 13:17.48 |
| | like the float/int number | 13:17.54 |
| Robin_Watts | Right, but then we have to cope with 4 varieties of pdf_namecmp. | 13:18.15 |
| tor8 | just add PDF_KNOWN_NAME to pdf_objkind | 13:18.41 |
| | and pdf_namecmp and pdf_to_name and pdf_new_name in pdf-object.c would be the only ones to know | 13:19.07 |
| Robin_Watts | What type would pdf_namecmp take? | 13:19.33 |
| tor8 | it would take an enum | 13:19.38 |
| | PDF_Name_Resources | 13:19.42 |
| | PDF_NAME_Resources | 13:19.48 |
| | it's the only way I see we can gain performance | 13:19.55 |
| Robin_Watts | pdf_namecmp takes 2 args. | 13:20.02 |
| tor8 | pdf_namecmp(pdf_obj *name, enum pdf_known_name name) | 13:20.24 |
| | or rather pdf_is_name(name, enum) | 13:20.40 |
| | still, I'm not convinced this will solve malc's problem or gain us enough speed to be worth cluttering the API | 13:21.08 |
| | uglifying, actually | 13:21.16 |
| | still, we could do with replacing all strcmp(pdf_to_name(ctx, obj), "blah") with pdf_is_name(ctx, obj, "blah") | 13:22.02 |
| Robin_Watts | It would remove a malloc for every name. | 13:22.28 |
| | That alone has to be a win. | 13:22.37 |
| tor8 | names are already only one malloc | 13:22.47 |
| | same as strings | 13:23.17 |
| Robin_Watts | Ah, right. That's where my idea wins. | 13:23.30 |
| | names become 0 malloc things. | 13:23.39 |
| tor8 | you mean to turn pdf_obj into a tagged pointer type? | 13:24.00 |
| | I'm starting to understand what you mean now, I thought you meant the obj->u.n pointer not the actual obj pointer | 13:24.35 |
| Robin_Watts | I hadn't considered pdf_obj, just names themselves. | 13:25.11 |
| tor8 | all names are pdf_obj's | 13:25.20 |
| | I don't see how that would change | 13:25.26 |
| Robin_Watts | Not the ones in dicts. | 13:25.28 |
| | oh, god they are too. | 13:25.49 |
| tor8 | we could preallocate a list of known name pdf_obj's in a global array | 13:26.29 |
| Robin_Watts | So we have the ability to have pdf dictionaries with non names as keys. | 13:26.31 |
| tor8 | then do if (obj == pdf_name_Resources) pointer comparisons | 13:26.47 |
| kens | PostScript! | 13:26.49 |
| Robin_Watts | Can postscript do that? | 13:26.59 |
| kens | Non-names as dict keys ? yes | 13:27.08 |
| Robin_Watts | But pdf can't, right? | 13:27.19 |
| kens | I believe not, no | 13:27.27 |
| tor8 | and pdf_new_name would first try to match up with one of the preallocated globals | 13:27.54 |
| | or statically allocated global | 13:28.03 |
| Robin_Watts | tor8: a statically allocated set of known globals would work. | 13:28.35 |
| | and would fit with our existing scheme of having a negative refcount to mean "static". | 13:29.22 |
| tor8 | yeah. | 13:30.10 |
| Robin_Watts | Will ponder all this. | 13:30.17 |
| kens | Robin_Watts : bug #695844, what's our Bugzilla attachment limit ? I thought it was 512 Mb | 13:46.14 |
| Robin_Watts | kens: I am not sure. | 14:16.38 |
| | yes, 512Meg. | 14:16.55 |
| kens | SO they should be able to just attach the file to the bug report then | 14:17.09 |
| Robin_Watts | assuming they are happy with it being unprotected for a few minutes. | 14:17.23 |
| kens | True. | 14:17.41 |
| pipitas | rayjj: { if you come back: my last statement about "gs -H doesn't work" was in reply to yours saying: "[GS â¦] treats -d and -D the same (also some others including -s and -S and -h and -?)" } | 14:42.22 |
| | ;-) | 14:42.24 |
| | rayjj: So I misunderstood your "-h and -?" part⦠| 14:43.09 |
| kens | Hmm bug #695845 I wonder if this is a customer, perhaps customer #400 ? I believe I recognise the name Tony Teveris :-( | 15:10.39 |
| | Ah yes, looks like its the same people. | 15:11.23 |
| rayjj | morning, all | 15:15.05 |
| kens | Morning Rayjj | 15:15.13 |
| Robin_Watts | Downloading the million page file now. | 15:25.30 |
| kens | Enjoy..... | 15:25.37 |
| | As I mentioned (on the original bug) they can get 2x performance from GS with the information they want simply by gathering both sets of information in one pass, instead of doing 2, one for each set. But that means some simple PostScript coding | 15:26.35 |
| henrys | kens: maybe point marcos to the bug and let him follow up with email | 15:28.22 |
| kens | The Tony Teveris one ? I did just fill in some info on it. THey are asking about 8.63 so there's no way Michael can say anything useful | 15:29.02 |
| henrys | kens: I just thought marcos should follow up with an email and repeat what you said more or less. | 15:30.22 |
| kens | Sure, no problemwith that | 15:30.36 |
| henrys | hi mvrhel | 15:30.59 |
| Robin_Watts | Morning mvrhel. | 15:31.08 |
| kens | thinks Michael's ears must be burning | 15:31.10 |
| mvrhel | uhoh | 15:31.35 |
| henrys | I was wating for marcos but let's start he'll catch up | 15:31.39 |
| mvrhel | I would def. prefer to stay away from an 8.63 bug | 15:32.39 |
| kens | We don't owe support on versions that old :-) | 15:32.50 |
| henrys | for the upcoming staff meeting can everyone put some thought into language switching and weigh in? Anything you can contribute. | 15:32.54 |
| marcosw | morning | 15:32.55 |
| kens | Morning | 15:33.01 |
| rayjj | henrys: mvrhel: IIRC, the spot_equivalent_color info predates 9.00 | 15:33.24 |
| kens | rayjj : But that will get him CMYK unless I misunderstand, and he wants RGB | 15:34.01 |
| henrys | even if it were we aren't support 8.63 and if we ask him to update he's going to go to the current release rayjj. right? | 15:34.48 |
| rayjj | henrys: one of the biggest headaches with l-s was trying to share the device amongst the parsers, since when they run singly, they 'own' the device. | 15:34.53 |
| henrys | rayjj: which leads to one of many questions. i.e. How does a system track page counts is a simple one. | 15:36.04 |
| rayjj | l-s will be a lot simpler if we close the device, then re-open it with the new parser | 15:36.04 |
| mvrhel | sorry what bug number is it kens. just curious | 15:36.16 |
| Robin_Watts | To do ls nicely, one would assume that we need to encapsulate all the parsers state into a single object. | 15:36.31 |
| kens | mvrhel : 695845 | 15:36.33 |
| | I would assume that we'd close down the iterpreter between jobs, or at least whenever we switch input language | 15:36.56 |
| Robin_Watts | And to 'start' and 'stop' each parser. | 15:36.57 |
| henrys | rayjj: I thought you were a proponent of having separate devices entirely for each language. | 15:37.07 |
| rayjj | henrys: isn't that what I just said? | 15:37.33 |
| chrisl | henrys: we could do a spec_op to retrieve and set the page number | 15:37.33 |
| Robin_Watts | kens: whether 'start'/'stop' creates/destroys the parser, or whether we have 'init'/'start'/'stop'/'fin' would be a point for discussion. | 15:38.15 |
| | When you 'start' such a parser, you'd pass the device in. | 15:38.27 |
| henrys | rayjj: no closing a device doesn't destroy the memory, I thought your scheme had 2 devices in memory. | 15:38.38 |
| Robin_Watts | When you 'stop' the parser, it would have to flush the device and let go. | 15:38.41 |
| kens | For PostScript the overhead will be the same, stopping and starting the interpreter is a big cost | 15:38.46 |
| | I don't believe you could 'pass the device in' for PostScript, our setpagedevice code would break I htink | 15:39.14 |
| rayjj | Robin_Watts: the thing is that there is parser "state" that has to be preserved -- PS has the job server state | 15:39.16 |
| chrisl | For Postscript we really must have the device set in Ghostscript, unlike the previous l-s scheme | 15:39.23 |
| rayjj | I don't think we should close the parser -- just close the device | 15:39.46 |
| Robin_Watts | well, 'stop' could get the device passed back out? | 15:39.50 |
| kens | rayjj that will lead to a lot of memory being used up | 15:40.01 |
| rayjj | Robin_Watts: why ?? | 15:40.06 |
| kens | Robin_Watts : No, tghat really isn't going to work, because its all tracked in PostScript | 15:40.16 |
| Robin_Watts | Ok. | 15:40.23 |
| kens | I've said it before, our setpagedevice is just awful | 15:40.43 |
| chrisl | Like with fonts, Postscript programs can know about, change and configure the device | 15:40.47 |
| rayjj | kens: why does that lead to a lot of memory being used ? The parser RAM is pretty small | 15:40.48 |
| Robin_Watts | I would imagine with a sane ls implementation, we wouldn't want to be able to set things in one parser and have them effect the next one. | 15:40.55 |
| kens | rayjj I was assuming you meant the whole PostScript state | 15:41.05 |
| Robin_Watts | hence a new device each time wouldn't be the end of the world, would it ? | 15:41.08 |
| kens | Devices aren't massivly huge, normally | 15:41.29 |
| | If we don't hold the PS state, then startup costs for the PS interpreter are quite large | 15:42.01 |
| Robin_Watts | Would we want to be able to set things in one PS file, and have them still in effect for the next one ? | 15:42.16 |
| kens | Only if the file was executed outside the server loop | 15:42.36 |
| | persistent state in PostScript is undefined, basically | 15:42.51 |
| Robin_Watts | kens: That's exactly the opposite answer I was expecting :( | 15:42.55 |
| kens | Unless you download to a disk | 15:43.00 |
| rayjj | kens: the big RAM usage for raster devices is the buffer | 15:43.03 |
| henrys | The model is simplified quite a bit if PS -> PCL -> PS does not save state for the second PS but PS -> PS should save state. | 15:43.33 |
| kens | Robin_Watts : the job server loop in PostScript is intended to prevent jobs interfering | 15:43.38 |
| rayjj | kens: persistent state in PS _is_ defined in the PLRM | 15:43.39 |
| Robin_Watts | kens: right. | 15:43.51 |
| | As a thing that serves jobs, it's reasonable that every PS file should get a clean slate. | 15:44.13 |
| kens | Indeed. | 15:44.21 |
| chrisl | Doing lazy switching is, I think, a good approach | 15:44.27 |
| kens | I would think we would not shut down anything unless we actually changed languages | 15:44.41 |
| chrisl | Exactly | 15:44.48 |
| Robin_Watts | Submitting several files/streams/whatever as a single job though, you want them to have the same state. | 15:45.01 |
| henrys | didn't I just say that .. ;-) | 15:45.20 |
| kens | Robin_Watts : that's not the way PS is supposed to work, each job is encapsulated by the jobserver | 15:45.21 |
| rayjj | Robin_Watts: kens: Things changed in VM outside the server 'save' (at save level 0) such as fonts downloaded, ARE expected to be there for subsequent jobs | 15:45.28 |
| kens | If you want them to affect each other you have to make them into one program | 15:45.38 |
| rayjj | several of the CET tests do this | 15:45.50 |
| chrisl | Robin_Watts: single a job is a single job, regardless of how many files/streams it takes up | 15:45.50 |
| henrys | mvrhel: how's the color customer? | 15:45.53 |
| kens | rayjj yes, but not necessarily if you turn off the printer | 15:45.56 |
| Robin_Watts | chrisl: right. | 15:45.58 |
| kens | IMO changing language is the same as power cycling the printer | 15:46.18 |
| Robin_Watts | yes. | 15:46.25 |
| mvrhel | henrys: All the parts have been committed | 15:46.34 |
| | I need to figure out how to deliver it to him | 15:46.43 |
| kens | rayjj by persistent state I meant after a power off. | 15:47.02 |
| | I did mention execution outside the job server loop | 15:47.15 |
| rayjj | kens: for power off, I agree. And we can leave that to the printer company to implement it. | 15:47.38 |
| mvrhel | henrys. network issue there. so I was saying that all the parts have been committed but I need to figure out the best way to deliver it to him | 15:48.21 |
| henrys | so we have to start thinking about the API etc. | 15:48.28 |
| mvrhel | I hate sending files which is what he wants | 15:48.29 |
| kens | rayjj IMO chaning language = power off. | 15:48.41 |
| Robin_Watts | Ok, suppose someone downloads such a font. Then sends a PS file that prints using that font. Then sends a PCL file. | 15:48.43 |
| | Then sends a PS file again - is the font still available ? | 15:48.53 |
| kens | Then the font is gone | 15:48.56 |
| | IMO | 15:49.00 |
| Robin_Watts | (by is I mean "should it be") | 15:49.02 |
| chrisl | It depends..... | 15:49.14 |
| kens | this is what I meant, the action in this case is undefined. | 15:49.16 |
| henrys | kens: well pcl can write fonts to disk and make them permanent resources. That should work okay. | 15:49.23 |
| kens | henrys, yes, so can PostScript, but that's not entirely what we mean | 15:49.43 |
| | Robin_Watts : is suggestging that a job contains a font (not written to disk), but executed ourtside the job server loop. Such a font is 'persistent' until the interpreter shuts down | 15:50.13 |
| Robin_Watts | I think we want a clear definition of what we'd want our implementation to do before we dive into coding anything. | 15:50.16 |
| henrys | kens: oh I thought for a printer we would turn that off in PS. | 15:50.19 |
| kens | So a subsequent PS file could use it | 15:50.21 |
| rayjj | if the parser stays "alive" (not terminated) then the PS job server state remains for subsequent jobs. I don't think we should force a "power cycle" when switching parsers | 15:50.41 |
| kens | The question then is, if we run a PCL file, and go back to PostScirpt, is the font still there int eh PS environment ? | 15:50.56 |
| | rayjj I think we should | 15:51.06 |
| rayjj | if nothing else, the performance hit on starting PS for every job will impact throughput. | 15:51.21 |
| Robin_Watts | kens: consider this as an example... | 15:51.31 |
| kens | Yes indeed, that's what I was saying earlier | 15:51.33 |
| henrys | rayjj: good point | 15:51.34 |
| kens | But if we *don't* shut the itnerpreter down, tehn we have a chunk of memory being used up | 15:51.59 |
| henrys | mvrhel: why not tarball on git.ghostscript.com and send it. | 15:52.04 |
| rayjj | since l-s is focused on printer customers, they tend to have slow CPU's and the initialization is significant | 15:52.05 |
| Robin_Watts | suppose i have a printer attached to my PC. I print a postscript job to it that sets a font. I then print another postscript job to it that uses that font. | 15:52.13 |
| kens | Robin_Watts : almost certainly tyour prtiner dirver will embed both fonts | 15:52.33 |
| | Printer drivers ain't that smart | 15:52.48 |
| Robin_Watts | I might feel annoyed if that gave different results if someone else printed a PCL job to my printer between my 2 PS jobs. | 15:52.54 |
| rayjj | kens: the amount of memory used by the PS state isn't all that large *if* we close the device (which frees it's buffer) | 15:53.01 |
| kens | rayjj I am unconvinced, but I have never looked | 15:53.20 |
| rayjj | Robin_Watts: correct. In particular on a networked machine | 15:53.22 |
| kens | Not going to happen, the PS will contain the fonts both times. | 15:53.35 |
| Robin_Watts | kens: I don't think "the driver will probably embed fonts" is a good argument. | 15:53.47 |
| henrys | keeping state is not really a problem if we keep it separate. The last ls failed because we didn't do that. | 15:53.59 |
| kens | Robin_Watts : I bet it is | 15:54.04 |
| rayjj | kens: I'll have a look at the RAM usage for the PCL state and PS state (those are the two most used) exclusive to the device buffer | 15:54.25 |
| Robin_Watts | People will expect PS to work as PS is defined to work. | 15:54.26 |
| kens | grr network | 15:55.10 |
| mvrhel | henrys: ok. I will send him an email | 15:55.12 |
| kens | At the very least we should consider the possibility of closing the interpreter each time, I bet a customer will ask for it | 15:55.31 |
| chrisl | Robin_Watts: In my experience, these details are totally dependent on the printer implementation: some printers will preserve state, others will reset.... | 15:55.40 |
| Robin_Watts | I haven't heard anything so far that seriously changes my initial thought that we should encapsulate the parser states nicely, and have an API for making one at a time current. | 15:55.47 |
| kens | We should ensure that we *can* close the interpreters down totally, otherwise someone will complain. | 15:56.10 |
| Robin_Watts | chrisl: Right. But *we* should decide up front how we'd most like it work. | 15:56.11 |
| rayjj | mvrhel: can you review the patch I mentioned last night (see the top of the logs) | 15:56.42 |
| Robin_Watts | kens: Yes, it seems reasonable that we'd want to offer a way to reset one (or more) interepreter states. | 15:56.45 |
| chrisl | Robin_Watts: *We* can't do that because *we* don't know in advance what a potential customer will want - *we* should account for both schemes | 15:56.46 |
| Robin_Watts | chrisl: But *we* can decide which schemes we will support. If we can offer the ability to do both, then great. | 15:57.23 |
| kens | I have no problem with whatever we choose as our default, but we must ensure the customer can have both. | 15:57.29 |
| rayjj | closing the parser is pretty simple, but I agree that we should provide for keeping them alive when switching language | 15:57.46 |
| kens | Because, form experience, if we don't the first cusomter will wnat whatever is the opposite of what we decide | 15:57.49 |
| rayjj | kens: agreed. | 15:58.05 |
| Robin_Watts | rayjj: so an init/start/stop/fin model would work well, I think. | 15:58.07 |
| | In the case where we want a fresh start each time we init then start, then stop then fin. | 15:58.34 |
| henrys | well we have to have a means to shut down the other interpreter in low memory conditions ... I have to think any printer customer will insist on that. | 15:58.54 |
| kens | Ratgher than discuss this now on IRC, maybe we should wait until the meeting and do it face to face ? | 15:58.55 |
| rayjj | Robin_Watts: and 'stop' is what closes the device ? | 15:58.57 |
| chrisl | I suspect the PCL interpreter is going to be a bigger problem for this stuff than Ghostscript...... | 15:59.13 |
| Robin_Watts | rayjj: start makes the parser current, stop puts it into the background. | 15:59.40 |
| rayjj | chrisl: why is PCL a problem ? | 15:59.43 |
| Robin_Watts | stop would certainly flush the device. | 15:59.46 |
| | IF you say that we can't share devices between parsers, then yes, start/stop would create/destroy the device. | 16:00.03 |
| chrisl | rayjj: I'm thinking of the memory issues Norbert encountered when starting and stopping the PCL interpreter | 16:00.18 |
| rayjj | Robin_Watts: in our graphics lib to device interface 'close_device' is what will free it's RAM | 16:00.34 |
| henrys | I did't have anything else important to bring up. Probably cancel next Tuesday keeping with tradition. | 16:00.53 |
| rayjj | chrisl: do you mean leaks ? | 16:00.56 |
| Robin_Watts | rayjj: Right. | 16:00.58 |
| chrisl | rayjj: yes | 16:01.05 |
| rayjj | henrys: 4 of us will be skiing next Tue anyway | 16:01.17 |
| kens | If we go back to the job server loop we will close the current devioce and fall back to the null device, which uses practically no memory | 16:01.31 |
| mvrhel | oh that reminds me | 16:01.32 |
| rayjj | (or at least driving to the slopes Tue AM) | 16:01.38 |
| mvrhel | we need to figure out our lift tickets | 16:01.41 |
| kens | Indeed | 16:01.46 |
| henrys | rayjj: oh you guys come before the meeting? | 16:01.49 |
| kens | Yes, we are flying on Mondya, holida Tue/Wd/Thurs | 16:02.05 |
| mvrhel | rayjj: you had said something about getting a multi-resort lift ticket? | 16:02.38 |
| rayjj | mvrhel: I saw the discussion yesterday -- if everyone just wants to stay at Copper, that's fine with me | 16:03.18 |
| kens | I'm happy with just Copper | 16:03.34 |
| rayjj | mvrhel: they used to have those, but I don't see those online | 16:03.37 |
| mvrhel | I don't either | 16:03.43 |
| tor8 | rayjj: mvrhel: kens: I'll leave any decisions up to you. | 16:03.47 |
| kens | The Vail pass said that 3+ days was multi-resort, Copper doesn't seem to say that | 16:03.56 |
| henrys | rayjj: we just had a foot of snow and more in the forecast so I've got to think the base is going to be in good shape. | 16:04.25 |
| mvrhel | great | 16:04.34 |
| rayjj | mvrhel: kens: tor8: I'm looking for discounts on lift tickets and/or equip rental. I'll let you know in a bit what I'm able to suss out | 16:04.45 |
| | henrys: GREAT :-) | 16:04.55 |
| kens | rayjj all the online sites for lift passes offer ~48% discount for online booking compared to the window proce at the resort | 16:05.17 |
| rayjj | we just got 16" locally Sunday and yesterday. Maybe that storm will visit you as well | 16:05.34 |
| tor8 | I'm off to see if I can buy some warmer ski clothes. anything I should keep in mind? it's been 10 years... | 16:05.35 |
| kens | I haven't made much sense of the rental, I was just going to walk into a shop on Tuesday :-) | 16:05.39 |
| | tor8 thermals, definitely | 16:05.52 |
| | Its going to be cold, make sure you have something to cover your neck and probably face at that temperature | 16:06.10 |
| mvrhel | yes | 16:06.21 |
| rayjj | tor8: neck warmer that you can pull up over your face, or a face mask | 16:06.38 |
| mvrhel | ok so lets just make this easier and stay at copper. I am going to buy a 3 day adult on line pass | 16:06.58 |
| kens | OK I'll do that too. I believe they are pick up at the lift | 16:07.15 |
| | FOr online bookings | 16:07.22 |
| rayjj | kens: probably so | 16:07.26 |
| mvrhel | kens: they have a lift+rental option I see | 16:07.37 |
| kens | I see several differnet ones. THe lift pass was the big cost though | 16:07.59 |
| | Also, I'm planning to bring boots, so I don't really want a full package | 16:08.18 |
| | I may change my mind depending on whether I can get my boots in my suitcase :-) | 16:08.31 |
| tor8 | kens: flying checked luggage for once? ;) | 16:08.56 |
| kens | Yeah, no real choice with ski-ing gear :-( | 16:09.10 |
| mvrhel | rayjj: that reminds me | 16:09.21 |
| | since I am bringing my board. I think I will mail the sax to you | 16:09.35 |
| | otherwise I am going to be overloaded | 16:09.40 |
| | with stuff | 16:09.42 |
| rayjj | darn. Senior price starts at 65 :-( | 16:11.03 |
| kens | Way to go yet..... | 16:11.15 |
| rayjj | mvrhel: OK about the sax | 16:11.26 |
| | kens: two more years | 16:11.32 |
| kens | Really ? I'm surprised | 16:11.52 |
| | Woudl have thought more | 16:12.09 |
| rayjj | mvrhel: fed ex ground was the cheapest way I found, but I didn't check the USPS | 16:12.16 |
| | miles is only a few months younger than me. Scott's the oldster | 16:12.58 |
| kens | :-D | 16:13.13 |
| mvrhel | ok. lift ticket purchased. now I need to run my board in to get waxed | 16:14.21 |
| kens | Visions of Michael sailing down the slopes | 16:14.51 |
| mvrhel | I am pretty slow | 16:15.19 |
| kens | I've been told I have to be :-) | 16:15.39 |
| rayjj | kens: tor8: mvrhel: This looks interesting: http://eduproject.com/the-e-book/ski-deals/ | 16:18.37 |
| kens | Might be worth for rental | 16:19.29 |
| | Oh except they don;t seem to be at copper | 16:20.02 |
| rayjj | kens: I'll check sports authority in Denver (rent Monday) | 16:21.51 |
| kens | Tuesday surely ? | 16:22.04 |
| | Oh you mean TOr and I could go there Monday ? | 16:22.20 |
| rayjj | kens: no, they probably don't open until 10am or so. We want to be on the road early Tue | 16:22.38 |
| kens | Yes, sure. I was assuming we'd pick up rentals on site at copper | 16:22.58 |
| rayjj | kens: it would be easier -- I'm not sure if there is price advantage to renting off mountain. Locally it's about the same | 16:23.49 |
| mvrhel | oh shoot they had a 2 for one lift ticket | 16:24.07 |
| kens | Beats me, I've never tried anything like that before. | 16:24.11 |
| | mvrhel : but only for one day, right ? | 16:24.19 |
| mvrhel | yes | 16:24.25 |
| | just get 3 | 16:24.30 |
| | oh I see | 16:25.08 |
| | its a book | 16:25.15 |
| kens | yeah | 16:25.49 |
| | OK my lift pass is booked. Another piece of paper to print out and bring.... | 16:33.21 |
| rayjj | mvrhel: are you talking about the link I posted? That book is only $10. | 16:33.23 |
| | so if the "full" rate is $128, then 2 for 1 is $64 each, compared to the $80/day that I see for 3 of 5 passes | 16:34.51 |
| | I did see one outfit that had 3 day pass incl rental for $330 | 16:35.22 |
| | only slightly off the $240 + $33.60 discounted online rental. | 16:36.14 |
| Robin_Watts | so mvrhel... let me know when you want to talk about the bonkers path bug. | 16:42.12 |
| mvrhel | rayjj: I missed the boat with that, as I already bought my 3 day pass | 16:52.21 |
| | Robin_Watts: we can talk now that is fine | 16:52.29 |
| Robin_Watts | ok. | 16:52.42 |
| mvrhel | I don't really have any idea though what to do about it | 16:52.47 |
| Robin_Watts | so there is nothing you can do about it. | 16:52.55 |
| mvrhel | I looked at the paths and they are not really closed | 16:52.56 |
| | or they are zero sized for the most part | 16:53.12 |
| Robin_Watts | mvrhel: They are closed enough for the purposes of postscript filling. | 16:53.17 |
| | 0 0 moveto 100 0 lineto 100 100 lineto fill showpage | 16:54.46 |
| | That will produce a triangle, even without the close. | 16:54.56 |
| mvrhel | right | 16:55.05 |
| Robin_Watts | Does xps differ? | 16:55.06 |
| chrisl | IIRC, the fill performs an implicit closepath | 16:55.18 |
| Robin_Watts | chrisl: urm... | 16:55.26 |
| mvrhel | Robin_Watts: the output that xps write was giving me was identical to what mupdf was drawing for the source pdf file | 16:55.48 |
| Robin_Watts | 0 0 moveto 100 0 lineto 100 100 lineto 200 0 moveto 300 0 lineto 300 100 lineto fill showpage | 16:56.03 |
| mvrhel | so the fill rule of xps is the same as what mupdf is doing | 16:56.05 |
| Robin_Watts | chrisl: 2 triangles. | 16:56.07 |
| | so fill does not do an implicit closepath. | 16:56.25 |
| | cos if it did, the first triangle wouldn't be closed. | 16:56.36 |
| | the process of filling does close subpaths effectively though. | 16:57.04 |
| | i.e. it's the process of filling, not the 'fill' operator. | 16:57.22 |
| | mvrhel: Right. | 16:57.27 |
| | So the difference is down to the way acrobat handles zero sized fill regions. | 16:57.45 |
| | (possibly with a splash of fill adjust in there too). | 16:58.03 |
| | Essentially you are producing a perfectly reasonable rendering of what the file specifies. | 16:58.18 |
| | Unless xps has some option to handle fill adjust in the same wierd way that acrobat does, I'd say that your results were perfectly valid. | 16:58.52 |
| mvrhel | ok. then we will leave it at that. | 16:59.03 |
| Robin_Watts | If you render in acrobat at high zoom (or in gs for that matter) you see the same issues as in mupdf. | 16:59.10 |
| mvrhel | oh interesting | 16:59.22 |
| chrisl | Robin_Watts: does changing the smoothing setting in Acrobat have any effect? | 17:00.16 |
| Robin_Watts | chrisl: I get the same in acrobat with display and with tiff export. | 17:01.17 |
| chrisl | Ah, okay..... | 17:01.28 |
| mvrhel | ok. I see it too. | 17:02.01 |
| | so we can close 695790 and 695792 | 17:02.43 |
| chrisl | Robin_Watts: from the PLRM: "Fill: Any subpaths that are open are implicitly closed before being filled" - so sort what both of us said.... | 17:02.53 |
| Robin_Watts | chrisl: Right. | 17:03.09 |
| | yeah, sorry, I misinterpreted your 'fill' to mean 'the operator' rather than 'the action'. | 17:03.29 |
| chrisl | terminology clash..... | 17:05.30 |
| Robin_Watts | mvrhel: I'm pondering whether there is a rendering hack I can do to make 695792 render correctly in mupdf. | 17:08.22 |
| mvrhel | Robin_Watts: ok. well I think I am probably stuck what I have for now with the xpswrite device. Perhaps there is some adjustment that could be done to the path but I don't think I have the time to try to figure it out now | 17:12.09 |
| Robin_Watts | mvrhel: No, you can't adjust the path unless you know the final resolution it's going to be rendered atl. | 17:12.37 |
| mvrhel | ok | 17:12.44 |
| | then I may just close the bug | 17:13.01 |
| chrisl | It seems to me this comes under the heading of incompatible imaging models..... | 17:13.36 |
| mvrhel | yes | 17:13.50 |
| Robin_Watts | mvrhel: I would close 695790 yes. | 17:14.02 |
| mvrhel | rayjj: you still here? | 17:14.50 |
| kens | AH, looks like I finally sorted out my memory problem, the cluster is actually running jobs | 17:17.02 |
| henrys | marcosw: we agreed yesteday that xpswrite problems should not be blockers. | 17:19.00 |
| marcosw | henrys: okay, as far as I can remember there is only one xpswrite bug that I made a blocker. | 17:20.38 |
| mvrhel | rayjj: to pdf14 optimize check commit looks good | 17:21.17 |
| henrys | marcosw: we should have reviewed blockers at the meeting today but we got carried away with language switching | 17:21.20 |
| kens | Can do it a week Friday | 17:21.37 |
| mvrhel | ok. so I have a alphabits blocker on my list | 17:22.52 |
| kens | That one looks more like a clist problem to me | 17:23.07 |
| | Granted its revealed by a change you made, but I'm not convinced that does more than expose the problem. Of course I could be wrong | 17:23.38 |
| mvrhel | yes. I wonder if rayjj would take a look at that | 17:23.41 |
| | rayjj: when you get back, would you be interested in having a look at 695485 | 17:24.32 |
| | he is poking around in clist transparency stuff right now anyway | 17:25.38 |
| kens | OK off to cook, night everyone | 17:34.33 |
| rayjj | mvrhel: thanks for the review. which one do you want me to look at ? | 17:34.37 |
| rayjj | goes to check the "blockers" | 17:34.55 |
| kens | rayjj I htink 695485 | 17:35.10 |
| rayjj | kens: thanks. That's what I assume: Regression: error with GraphicsAlphaBits=4 starting with fdc21fee6c1679b641d9f296fafac9c1a4fff19d | 17:36.06 |
| | I have to run something over to the school. bbiab | 17:36.23 |
| kens | Yes, but the trackback makes it look like a clist problem | 17:36.28 |
| henrys | mvrhel: why not tell him to grab a snapshot at http://git.ghostscript.com/?p=ghostpdl.git;a=summary | 17:38.23 |
| Robin_Watts | why not tell him to learn to use patch, or to do it manually? :) | 17:39.04 |
| jogux | did someone review fred's mupdf ios fixes? golden doesn't build for iOS for me. | 17:40.11 |
| Robin_Watts | I did not. | 17:40.27 |
| | I think tor had looked and said something about tabs and trailing spaces. | 17:40.39 |
| | but fred has not been on irc to talk to. | 17:40.49 |
| | dunno if tor mailed him. | 17:40.54 |
| jogux | ah yes, that sounds familiar. | 17:40.57 |
| Robin_Watts | It also does not build on windows for me. Looking at that now. | 17:41.09 |
| jogux | I didn't know we were allowed to push stuff to golden that doesn't build :-) | 17:41.25 |
| Robin_Watts | jogux: We aren't, generally. | 17:41.48 |
| | but the cluster doesn't catch windows or ios builds. | 17:41.55 |
| jogux | ahhhh! | 17:42.05 |
| chrisl | jogux: as long as it builds for tor it must be right ;-) | 17:42.11 |
| Robin_Watts | and this is a major refactoring, so we expect ports to be broken at the moment. | 17:42.11 |
| jogux | I think we might want a better commit message for fred's change too | 17:42.43 |
| | oh. I'm looking at wrong commit actually. but it could mention iOS perhaps. | 17:43.22 |
| | robin: I'd perhaps argue for having it on a branch till the ports are fixed | 17:44.34 |
| | hmm. something is massively screwed. random rectangular reasons of content go missing when zooming. | 17:50.13 |
| Robin_Watts | jogux: Crap. Where did you build from? | 17:53.29 |
| jogux | golden/master + fred's ios fixes. | 17:53.39 |
| | just trying 4fe9caafead64704a16c7093b72115893be3087f (which I think is pre-api changes) | 17:53.47 |
| | git clean -x -f -d is sufficient to make sure I've not got any left behind crud from previous attempts, right? | 17:54.23 |
| Robin_Watts | jogux: maybe. | 17:54.32 |
| jogux | 4fe9 <etc> seems fine. | 17:54.55 |
| Robin_Watts | How about e9411ab ? | 17:55.48 |
| | That's my display list rework. | 17:55.53 |
| | It's possible that screwed stuff. | 17:55.57 |
| | (though it tested out clean) | 17:56.05 |
| | That's before the API too. | 17:56.08 |
| | oh, no, sorry, that's post api, but before the html stuff. | 17:57.04 |
| jogux | let me try pre e94 but with fred's fixes. | 17:57.36 |
| Robin_Watts | but e9411ab + freds fix should build. | 17:57.37 |
| | right, thanks. | 17:57.44 |
| jogux | I didn't do what I said. e94 + fred's fix is bad. | 17:58.53 |
| Robin_Watts | ok, but is e94~1 + freds fix bad? | 18:00.03 |
| jogux | just trying :) | 18:00.15 |
| | 4fcc4fecd19b793591dd17d77217881db2f75cf6 + fred's changes seems okay | 18:02.44 |
| jogux | tries e94+freds fix again. | 18:03.31 |
| mvrhel | henrys: good point about the snapshot | 18:03.48 |
| jogux | Robin_Watts: yeah. your display list changes do seem suspect. sorry :-( | 18:04.00 |
| Robin_Watts | jogux: crap. | 18:04.33 |
| | but thanks for spotting it. | 18:04.45 |
| | I'll be miscalculating some bounding rectangles or something. | 18:05.01 |
| | or cocking up the skipping of content. | 18:05.28 |
| | oh! It'll be exactly the skipping of content. | 18:05.39 |
| | I am so fool. | 18:05.55 |
| jogux | I'd tend to say skipping. sometimes I'm missing the background but have the piece of text. | 18:05.58 |
| | in fact I think it's missing objects that are partially off the screen? | 18:06.30 |
| | hm. no. not exactly that. | 18:06.51 |
| Robin_Watts | Every object gets a rectangle. If the rectangle is off screen, we skip it. | 18:07.18 |
| | We have clever code to skip forward over clips/groups that are completely off screen, but that will be skipping over graphic state changes now :( | 18:07.54 |
| | so I need to think about that. | 18:08.04 |
| jogux | d'oh :-( | 18:08.15 |
| | step 1: add a test that fails? :-) | 18:08.43 |
| Robin_Watts | oh, hmm. maybe we don't. | 18:08.46 |
| | It's just tiled stuff we skip over. | 18:08.55 |
| | but that will go wrong. | 18:09.05 |
| | backgrounds missing could easily be tiles though. | 18:09.13 |
| | lots of files are generated by cairo, and that uses tiles for the sake of it. | 18:09.22 |
| | jogux: The cluster doesn't do any interactive tests like ATS. | 18:09.45 |
| | It just runs mudraw. | 18:09.56 |
| jogux | mudraw would nominally fail if asked to draw a segment of the page? (if that's possible) | 18:11.01 |
| Robin_Watts | jogux: Hmm. The cluster tests mudraw in banded mode. | 18:11.22 |
| jogux | emails a video in case it helps. apologies for dodgy camera work, screen recording didn't seem to want to play ball today. | 18:11.51 |
| Robin_Watts | Oh, it uses a displaylist, but has the band be the full size of the page. | 18:12.00 |
| | That looks like dodgy bboxes :( | 18:16.14 |
| | which file was that? | 18:16.47 |
| jogux | file emailed :-) | 18:17.23 |
| Robin_Watts | Thanks. | 18:17.29 |
| jogux | as any end user would say, it's broken on all files :-) | 18:17.44 |
| | xps is unhappy too, if that helps. | 18:18.58 |
| Robin_Watts | yeah, it would be. the displaylist is format independent. | 18:20.09 |
| jogux | that's enough for today I think. Tomorrow I might try and do the iOS refactoring I was trying to do tonight :-) | 18:22.21 |
| | 64bit builds are no more broken than 32bit afaict, although there are a few warnings (some in the core, some in the ObjC). I may try and sort some of those. amazingly they 'just worked'. | 18:24.02 |
| Robin_Watts | rectangles look identical on old and new versions. Display list dump looks identical too. | 18:35.23 |
| | That's even with me pumping a non identity transform into it. | 18:35.52 |
| | Ah! I see it I think. | 18:38.45 |
| | 2 commits on robin/master (not at the top though, sorry) | 18:46.41 |
| | 3 commits. | 18:56.54 |
| Neo1995 | Hello? | 20:41.34 |
| rayjj | hi, Neo1995 | 20:41.48 |
| henrys | I won't say "take the blue pill" | 20:43.14 |
| rayjj | Neo1995: as ghostbot is fond of saying, "if you have a question, just ask it, don't ask if you can ask a question" | 20:43.31 |
| | henrys: blue pill ? | 20:44.05 |
| Neo1995 | Yeah all right now I am on Kali Linux,I have cloned the git repo and followed the instructions in README | 20:44.07 |
| | OH sorry I am asking about mupdf | 20:44.31 |
| rayjj | Neo1995: which product | 20:44.36 |
| | oops. I typed too slowlly | 20:44.47 |
| Neo1995 | I have run the make commands and I got the reponse also. man mupdf is showing me the manpage | 20:45.07 |
| | But when I type mupdf I get "command not found" | 20:45.25 |
| rayjj | Neo1995: did you do "make install" ? | 20:46.13 |
| Neo1995 | Yes | 20:46.19 |
| Robin_Watts | Neo1995: Do you have X installed? | 20:46.34 |
| Neo1995 | Yes | 20:46.38 |
| Robin_Watts | do you have 'mudraw' (as a command) | 20:46.59 |
| malc_ | Neo1995: mupdf-x11 | 20:47.08 |
| Neo1995 | Thanks a lot guys,it worked. | 20:47.59 |
| rayjj | Neo1995: what does /usr/local/bin/mu* show ? | 20:48.13 |
| Neo1995 | But in my previous Ubuntu installation.All I had to do was type mupdf and it would come | 20:48.37 |
| rayjj | Neo1995: (oops I meant ls /usr/local/bin/mu*) | 20:48.44 |
| Neo1995 | mupdf-x11 | 20:49.19 |
| | Now how do I set it to my default pdf reader? | 20:49.51 |
| rayjj | Neo1995: it should have more than that (mudraw, mutool, mujstest, and mupdf-x11-curl) | 20:50.27 |
| Neo1995 | Yes those are there | 20:50.40 |
| rayjj | Neo1995: that depends on which desktop you are using, and not something I can answer since I don't mess with default apps on linux | 20:51.36 |
| Neo1995 | Is it possible to do it using the shell? | 20:52.04 |
| fredross-perry | re: trailing whitespace - someone please tell me what I need to do, if anything. Thanks. | 20:52.28 |
| | ⦠which I can do tomorrow (today is jammed up). thanks. | 20:53.15 |
| rayjj | Neo1995: huh? the shell just does what you tell it to do. The desktop 'file manager' is to only thing that will (possibly) try and open a file with some default app based on the "extension" | 20:53.54 |
| tor8 | fredross-perry: configure your editor to use tabs and delete trailing whitespace :) | 20:54.59 |
| rayjj | fredross-perry: we have guidelines for "style" and you should have git set up to check for trailing whitespace and spaces vs. tab indent. | 20:55.17 |
| tor8 | fredross-perry: run scripts/gitsetup.sh in the mupdf directory if you're on a linux/macosx machine | 20:55.40 |
| Neo1995 | rayjj:Ok That was a thoughtless question.I just want it that way because in my previous installation of Ubuntu I was able to do it. | 20:55.47 |
| tor8 | that should set some git flags to automatically fix some whitespace errors when committing | 20:55.56 |
| rayjj | fredross-perry: but I don't know if we use the git pre-commit checks with the mupdf git (we have that for the ghostpdl git) | 20:56.12 |
| tor8 | and an alias command "git wsfix" | 20:56.20 |
| fredross-perry | I see. Did not know that. | 20:56.50 |
| rayjj | tor8: BTW, the gitsetup.sh works for the msysgit shell on Windows as well | 21:00.38 |
| rayjj | just tried it | 21:00.55 |
| kristian_on_linu | cheers | 22:35.33 |
| | been struggling with this for an hour... mogrify *.pdf -format png -quality 100 file.png (for instance) gives me: ./base/gsicc_manage.c:1031: gsicc_open_search(): Could not find srgb.icc sfopen: gs_parse_file_name failed. | 22:36.16 |
| | however, there is a /usr/share/ghostscript/9.10/iccprofiles/srgb.icc | 22:36.51 |
| | OS is a brand new Linux 17 | 22:37.03 |
| | am I making sense? | 22:38.19 |
| | OK... seems to be a bug in my gs (9.10) so will take it from there... | 23:18.25 |
| | Forward 1 day (to 2015/02/25)>>> | |
IRC Logs