| | <<<Back 1 day (to 2015/08/25) | 20150826 |
| sebras | tor8: do you mind taking a cursory glance at sebras/jpegxr today? | 09:13.05 |
| | tor8: I'd like to get it merged quite soon. :) | 09:13.33 |
| tor8 | sebras: okay. | 09:13.46 |
| sebras | and off from my todo-list. | 09:13.46 |
| | tor8: ty! | 09:13.53 |
| tor8 | sebras: oh, right! I was going to fix up the jpegxr thirdparty commit authors and set up the repository. | 09:15.00 |
| sebras | tor8: yup. I also remember now that I forgot to send you the patches I have done to jpegxr, so I guess you will be unable to compile it right now. | 09:16.33 |
| | mupdf with jpegxr-support I mean. | 09:16.45 |
| tor8 | sebras: the switch in jxr_unpack_sample looks really weird | 09:16.53 |
| | sebras: can't you merge the info and state structs? | 09:20.07 |
| sebras | tor8: I know. the intent is to be able to take several of those cases and bring them back into JXR_BD32F. | 09:20.22 |
| tor8 | sebras: you've mixed if and case at the same block level... | 09:21.15 |
| sebras | tor8: I didn't know how to leverage the enum checking from the switch (did you check all the enum values?) with converting fixedpoint and half-precision floating point etc into 32-bit floats and then do the final conversion from 32-bit float to uint8_t in a single place. | 09:21.47 |
| | tor8: I know! intentionally. :) | 09:21.55 |
| tor8 | if (bpc == JXR_BDRGBE) case JXR_BDRGBE: bla blah; break; else if (bpc | 09:22.01 |
| | oh. ick. | 09:22.24 |
| | just use goto instead? | 09:22.34 |
| sebras | tor8: does that work inside a switch-statement? | 09:22.50 |
| tor8 | goto? it works elegantly. | 09:22.58 |
| sebras | tor8: ok, then I'll definitely use that approach. | 09:23.14 |
| | tor8: I didn't like what I wrote myself, but I didn't know how to make it better. :) | 09:23.28 |
| | even though it is a bit messy I hope that you get what the code is meant to do at least. | 09:24.06 |
| | for BD32F there is a non-linear conversion that I simply borrowed from another jpegxr-lib at the moment. | 09:24.45 |
| | I don't understand the numbers (yet). | 09:24.53 |
| tor8 | goto unpack_floats; and add the unpack_floats label in the switch at the right location. | 09:25.06 |
| sebras | I think this has to do with conversion between scRGB and sRGB, but I'm not sure. | 09:25.10 |
| | tor8: yup, I got it. | 09:25.18 |
| tor8 | sebras: apart from the ugly switch, and the IMO rather pointless separation of state and info structs, everything looks reasonable at a glance | 09:27.52 |
| | some minor formatting gripes, but those are trivial to fix (multiple consecutive blank lines, unnecessarily broken lines, a few things like that) | 09:28.47 |
| | sebras: in jxr_read_image, you create the image and set the pixel format and container parameters, then do nothing further in the only_metadata case | 09:30.15 |
| sebras | tor8: alright, good. next we have the changes to thirdparty/jpegxr, but I'll have to send those as a patch for you tonight (my computer at home isn't powered so I can't get at the patches right now) | 09:30.21 |
| tor8 | sebras: okay. | 09:30.31 |
| sebras | tor8: yes, I think there might be a chance that we can use jxr_get_IMAGE_CHANNELS() to determine what colorspace to use. | 09:31.05 |
| | tor8: instead of hardcoding the number of channels in the list of supported pixelformats. | 09:31.51 |
| | tor8: I'm unsure if jxr_get_IMAGE_CHANNELS() returned 0 up until the first time that jxr_decode_block() was called. if it is we need to keep the hardcoded number of components and I can move the call to jxr_create_input() into the if-statement. | 09:34.06 |
| tor8 | sebras: I'd hoiste the fz_mini(n, get_IMAGE_CHANNELS ...) calculation out of the for loop in jxr_unpack_sample. it makes the line very long, and it's an optimization. | 09:36.05 |
| sebras | tor8: seems reasonable. | 09:37.28 |
| | tor8: oh and I hadd JXR_BDRGBE because RGBE is normally set to JXR_BD8, but requires special processing anyway. | 09:38.02 |
| | hadd->add | 09:38.10 |
| | tor8: btw if you know of a better way to cast a 32-bit entity into a float I'm all ears... | 09:51.05 |
| tor8 | two ways I know of -- via a pointer like you've done or using a union. I think a union is the recommended way if reading the spec strictly. | 09:53.21 |
| sebras | tor8: ok, via pointer was the terser way so I opted for that. do you want me to use a union instead? | 09:53.55 |
| tor8 | I'd use a macro :) | 09:54.14 |
| | or a static inline function | 09:54.31 |
| sebras | maybe we do similar things elsewhere and in that case putting a static inline function into some fitz header would make sense. | 09:55.03 |
| | I'll look into that later tonight as well. | 09:55.13 |
| mvrhel_laptop | morning. Hi Robin_Watts. Did you get a chance to look at the commits on my repos? | 14:12.12 |
| Robin_Watts | mvrhel_laptop: Sorry, no, have been buried in SOT stuff. | 14:44.53 |
| | I hope to get to them in the next hour. | 14:58.49 |
| Vladyslav | hi all! I'm developing a win8.1 app and I have a some problems with saving images on pages pdf document using mupdf. I getting IRandomAccessStream on image, creating decoder and decode data using api from wincodec.h, creating fz_pixmap, creating fz_image, filling image and write pdf document. but the size of saved images almost 10 times more then size of original images. and I get a very big pdf file. anybody explain me please | 15:38.36 |
| kens | Sounds to me like you are writing the rendered image as a PDF file. | 15:39.21 |
| | bitmap data is very likely to be larger than the original (vector) PDF | 15:39.43 |
| Robin_Watts | Vladyslav: Hi. Are you a commercial, or a supported customer of Artifex? | 15:39.44 |
| Vladyslav | Robin_Watts: I'm a commercial | 15:42.44 |
| Robin_Watts | ok. | 15:43.46 |
| | Can you describe a bit more slowly exactly what you are trying to do, please? | 15:44.04 |
| Vladyslav | kens: the images size 10 times greater, is it possible? | 15:46.35 |
| Robin_Watts | Vladyslav: Without understanding what you are trying to do, we cannot comment with any accuracy. | 15:47.10 |
| kens | Vladyslav : I suggest you discuss it with Robin_Watts. However.... ther original PDF file probably had the page description as vector data. If you render that to an image it can easily be 10 or more times larger than the original PDF file, depending on the resolution. | 15:47.39 |
| Vladyslav | Robin_Watts: ok, now | 15:47.43 |
| | I'm a c++ dev. I need create a function, which will store the collection of jpeg images like a pdf. I getting a list of IRandomAccessStream and empty PDF file from C#. I create IWICBitmapDecoder from stream and decode pixels using api from wincodec.h. further, I create fz_pixmap using fz_new_pixmap_with_data(pdfCtx, cs, frameSize.x, frameSize.y, frameData.data()) and create image using fz_new_image_from_pixmapfz_new_image_from | 15:57.18 |
| Robin_Watts | Vladyslav: I said slowly! :) | 15:57.35 |
| marcosw | some time ago I think someone here mentioned a replacement cmd.exe for windows that was more unix like but didn't include all of the junk that mingw and cygwin include. Does anyone know what I'm talking about? | 15:57.40 |
| kens | There's PowerShell, don't know if yo would count that marcosw | 15:58.07 |
| Robin_Watts | marcosw: clink. | 15:58.20 |
| | Vladyslav: Right, so as I understand it, you are taking a jpeg image, and decoding it pixel by pixel. | 15:59.00 |
| | You then feed that pixel data back to MuPDF as an fz_pixmap. | 15:59.21 |
| | MuPDF will not compress that data (or if it does it will be by a lossless compression method like flate). | 15:59.50 |
| | consequently you will see the resultant filesizes being much larger than before. | 16:00.28 |
| marcosw | Robin_Watts: thx, that was it. | 16:00.54 |
| Robin_Watts | marcosw: I really strongly recommend ConsoleZ too. | 16:01.09 |
| marcosw | great, now I have a choice. | 16:01.47 |
| Robin_Watts | If you want to put the jpegs into the PDF as JPEGs rather than raw data, then you want to make an fz_image from the jpeg data without uncompressing it. | 16:01.48 |
| | ConsoleZ is a replacement for 'Command Prompt'. i.e. the gui bit that puts the shell in a window. | 16:02.26 |
| | The actual command prompt that ConsoleZ runs can be any shell you like. I have msys git bash, cygwin, and cmd (with clink) all set up here. | 16:03.06 |
| | It means I can have lots of different prompts in the same tabbed window, and swap between them easily. | 16:03.28 |
| | And I can do sane cut/paste. | 16:03.35 |
| | Vladyslav: Did that make sense? | 16:03.52 |
| marcosw | Robin_Watts: that does seem useful. | 16:04.04 |
| Robin_Watts | ConsoleZ is pretty much the first thing I install on any windows box. | 16:04.26 |
| fredross-perry | Robin_Watts: if there is a new libgs.so or mupdf I should be trying, please let me know. Thanks. | 16:04.38 |
| Robin_Watts | fredross-perry: I have *just* downloaded mvrhels stuff, but haven't had a second to look at it in detail. | 16:05.04 |
| | I will make a libgs.so as soon as I can. | 16:05.10 |
| fredross-perry | thatâs cool. | 16:05.16 |
| Vladyslav | ok, I have 40 images and they size 6,5Mb but after saving this in PDF I getting pdf file with size equals 176Mb. It is possible? | 16:05.38 |
| Robin_Watts | Vladyslav: Absolutely. | 16:06.04 |
| | My camera takes 18MP images. Saved as jpegs they are 5Meg each or so. | 16:06.53 |
| | Saved as raw data they would be 56Meg. | 16:07.30 |
| | Effectively you're putting raw data into the pdf file. | 16:07.48 |
| Vladyslav | it means that where I decode pixels from stream - I getting a raw data? | 16:10.24 |
| Robin_Watts | Vladyslav: If you are pulling out pixel values, and poking them into an fz_pixmap, yes. | 16:10.56 |
| Vladyslav | ok, thx | 16:13.08 |
| Robin_Watts | So, do you understand how to avoid that expansion? | 16:14.05 |
| | mvrhel_laptop: Your changes look plausible to me. Pushing them now. | 16:14.53 |
| | I'll rebuild libgs.so for fred now. | 16:15.06 |
| Vladyslav | not yet. if I will be convert stream to byte array and insert it in fz_pixmap - it will help? | 16:21.05 |
| Robin_Watts | Vladyslav: fz_pixmaps can only represent decoded images (i.e. raw data). | 16:21.54 |
| | fz_images contain the compressed data. | 16:22.07 |
| | So if you convert the stream to a byte array, and then make an fz_image from that byte array without touching fz_pixmaps, you should be fine. | 16:22.33 |
| Vladyslav | ok, thanks! I will try it now | 16:24.07 |
| chrisl | Robin_Watts: if you still think it would be preferable, it might be worth retrying the gs.a build with the latest changes - it might actually work for you now. | 16:24.51 |
| Robin_Watts | chrisl: No, a libgs.so works well. | 16:26.14 |
| | I should have done that in the first place, but shared lib stuff scared me a bit. | 16:26.27 |
| chrisl | Okay | 16:26.34 |
| mvrhel_laptop | Robin_Watts: ok thanks | 16:26.37 |
| Robin_Watts | but your changes might help mvrhel_laptop or fredross-perry. | 16:26.49 |
| | chrisl: fredross-perry was noting the other day that the gsapi functions are only present in the .dll/.so | 16:27.10 |
| chrisl | It was fredross-perry's problems that prompted me to find the problem | 16:27.13 |
| Robin_Watts | Ah, right. | 16:27.22 |
| | fredross-perry: New libgs.so in the usual place. | 16:27.42 |
| fredross-perry | Robin_Watts: thanks | 16:27.54 |
| Robin_Watts | I've just pushed mvrhel_laptop's mupdf changes too. | 16:27.56 |
| chrisl | Robin_Watts: the new build broke the .a target by not including most of the sources in psi | 16:28.06 |
| Robin_Watts | chrisl: oops :) | 16:28.20 |
| fredross-perry | Iâll make another android build i maube an hour. | 16:28.37 |
| Robin_Watts | fredross-perry: So, hopefully with this stuff, you should get much more color correct results. | 16:28.47 |
| fredross-perry | hopng | 16:28.55 |
| Robin_Watts | If I'm understanding this correctly, we should really be allowing the post render profile to be set within mupdf. | 16:29.28 |
| | cos the post render profile should change according to the device that mupdf is being run on. | 16:29.40 |
| | mvrhel_laptop: Have I got that right? | 16:29.44 |
| mvrhel_laptop | yes | 16:30.05 |
| | I want to add two things to the gproof spec | 16:30.22 |
| | one is a profile for the CMYK printer that we are proofing | 16:30.40 |
| | right now we are using SWOP CMYK by default | 16:30.52 |
| Robin_Watts | either a profile, or a pointer to such a profile, yes. | 16:30.59 |
| mvrhel_laptop | the other is the profile for the RGB device that we are viewing the image on | 16:31.05 |
| Robin_Watts | right. | 16:31.10 |
| mvrhel_laptop | with the above changes that is now sRGB | 16:31.18 |
| | with ultraHD devices that have massive gamuts the use of profiles other than sRGB will be of interest in the future | 16:32.01 |
| | anyway I may hack away at that tonight | 16:32.21 |
| | but I don't know if it is needed for the demo | 16:32.33 |
| Robin_Watts | mvrhel_laptop: I don't think it's strictly needed no - certainly they can demo what we have here. | 16:32.59 |
| mvrhel_laptop | yes | 16:33.11 |
| | but some of the proofing people that henrys shows this to might be interested. if we can pull it in easily we might want to | 16:33.57 |
| Robin_Watts | mvrhel_laptop: Yeah, that matches my thoughts. We have the basic demo now, anything else like this is icing on the cake. | 16:35.37 |
| | but desirable icing. | 16:35.46 |
| mvrhel_laptop | sounds good | 16:35.55 |
| marcosw | henrys: I just entered a P1 bug but am not sure who to assign it to, suggestions?: http://bugs.ghostscript.com/show_bug.cgi?id=696167 | 16:35.55 |
| Robin_Watts | marcosw: That's a PDF interpreter bug. | 16:36.36 |
| | which means it's kens, ray or chrisl. Probably kens, I would have thought? | 16:37.14 |
| marcosw | yeah, but if I assign it to ken he will say it's caused by the PDF file violating the spec. | 16:37.50 |
| chrisl | marcosw: I would look at what else the pdf interpreter does when you just use "run" | 16:38.30 |
| marcosw | chrisl: thx, Ive assigned the bug to ken but will keep working on using your suggestion. | 16:41.42 |
| Robin_Watts | If it's a broken file, and it depends exactly when the repair is run, then kens predicted comment would be correct :) | 16:42.05 |
| chrisl | marcosw: FWIW, /dopdfpages sets a bunch of stuff before doing the pdfgetpage pdfshowpage calls | 16:42.38 |
| marcosw | 2 2 dopdfpages also produces output with the data missing | 16:47.50 |
| chrisl | marcosw: I know what the missing part is - I'll update the bug | 16:53.32 |
| | marcosw: bug updated | 16:56.25 |
| marcosw | chrisl: thx | 16:57.08 |
| chrisl | marcosw: just double check it works! ;-) | 16:57.23 |
| marcosw | I did and have closed the bug. And am emailing the customer now. | 16:59.45 |
| chrisl | Cool - nice easy one! | 16:59.58 |
| marcosw | btw, is there any documentation on this? I wasn't familiar with the pdfgetpage/pdfshowpage method of rendering PDF pages. | 17:05.25 |
| chrisl | No, really, that's internal use only. We occasionally tell people about it when they need something that can't be done any other way | 17:06.33 |
| | We'll try not to change it, since some folks do use it, but we like to reserve the right to change it if we have to | 17:07.45 |
| marcosw | No one has asked about it in the last 8 years, so presumably not being documented isn't a big problem. | 17:09.06 |
| | bbiaw. | 17:09.19 |
| fredross-perry | So with the latest code, the âblack with spot orangeâ issue has changed. When viewing Altona-Testsuite_p2_S_x3.pdf, the non-proof view still looks sepia (unlike Preview). But the proof view looks orange as it should. And when I disable the âOrangeâ separation, it looks b/w. | 17:53.55 |
| | as it should | 17:54.12 |
| Robin_Watts | So that properly shows the benefits of proofing mode. | 17:55.33 |
| | fredross-perry: What separations are actually used on that page? just black and orange? | 17:57.21 |
| fredross-perry | no, cmyk plus orange. | 17:57.43 |
| | I am getting puzzling results from Altona.Page_3.2002-09-27.pdf however. | 17:58.13 |
| Robin_Watts | right, but c/m/y don't have anything on them ? | 17:58.36 |
| fredross-perry | In Altona.Page_3.2002-09-27.pdf there are areas of alternating MyBlue and MyRed stripes behind text. If I turn off either MyRed or MyBle, all the alternating stripes disappear. | 17:59.19 |
| Robin_Watts | fredross-perry: I can think of one reason why that might happen. | 17:59.56 |
| fredross-perry | In Altona-Testsuite_p2_S_x3.pdf, cmy and k all have something in them. The photo in the upper right just has black and orange. | 18:00.09 |
| | yes? | 18:00.19 |
| Robin_Watts | If you have all the separations selected, we show the color correct version. | 18:00.31 |
| fredross-perry | are you talking about orange right now? | 18:01.00 |
| Robin_Watts | No, the MyRed/MyBlue. | 18:01.21 |
| fredross-perry | ok | 18:01.30 |
| Robin_Watts | If we disable any of the separations at all, we do our own separations -> rgb conversion using the equivalent colors. | 18:01.32 |
| fredross-perry | interesting. | 18:01.43 |
| Robin_Watts | If MyRed and MyBlue are showing as having blank equivalent colors, then they would disappear when we disable any one of the components. | 18:02.15 |
| | Make sense? | 18:02.44 |
| fredross-perry | Sure. But would their having blank equivalent colors be a bug? | 18:03.35 |
| Robin_Watts | It would. | 18:03.44 |
| | I'd be tempted to either look at the gprf file in a hex editor, or to add some logging to see what the equivalent colors are. | 18:04.25 |
| | If they are blank, then that's one for mvrhel. | 18:05.08 |
| fredross-perry | So actually, thereâs this. The Android app gets the color from the Separation, and shows a swatch next to the name. No swatch for Orange. Or, for MyRed and MyBlue. | 18:07.03 |
| Robin_Watts | No swatch at all? Not a black swatch ? | 18:08.58 |
| fredross-perry | not black. SO, probably white. Iâll check⦠| 18:09.43 |
| Robin_Watts | The swatches are shown from the rgba equivalent color. At the moment, the 'a' of the rgba is always set to solid, so there should always be something there. | 18:09.55 |
| | white in the rgba would be indicative of 0000 in the cmyk, so nothing will show up when blending. | 18:10.28 |
| | So, we need to ask mvrhel_laptop why we're getting no equivalent color. | 18:10.54 |
| | Actually, let me run the file quickly here and see if I can spot anything obvious. | 18:11.05 |
| henrys | Robin_Watts: when you have a few minutes I'd like to talk about lib_ctx initialization. | 18:11.28 |
| Robin_Watts | henrys: Sure. Just let me run this and I'll be right with you. | 18:11.59 |
| | fredross-perry: Where did you get that file? That's not one I have here. | 18:13.46 |
| fredross-perry | MyRed and MyBlue are both FFFFFFFF (the rgba value in Separation | 18:13.50 |
| | which file? | 18:14.07 |
| Robin_Watts | fredross-perry: yeah. It's the CMYK values that matter for blending, but I imagine that would be 0. | 18:14.16 |
| | Altona.Page_3.2002-09-27.pdf | 18:14.19 |
| | I see it on casper. Copying it now. | 18:15.08 |
| fredross-perry | ok. | 18:15.30 |
| | I had trouble connecting to peeves just now | 18:16.12 |
| Robin_Watts | peeves is connected to the net by a wet piece of string. | 18:17.27 |
| | or at least it was. Ray may have had his internet improved, but it always used to be a pain. | 18:17.54 |
| | fredross-perry: OK. I've dug deeply enough to see that this looks like an issue for mvrhel :) | 18:18.56 |
| | so I'm going to run away. | 18:19.05 |
| | henrys: OK, shoot. | 18:19.13 |
| henrys | yeah I think he made the move to 2400 baud | 18:19.14 |
| fredross-perry | Brave Sir Robin | 18:19.19 |
| henrys | speaking of mvrhel_laptop | 18:19.32 |
| Robin_Watts | Has anyone heard anything from ray since yesterday? I'm hoping everything went well. | 18:20.53 |
| henrys | so pcl gets it's "gs_memory_t" with gs_malloc_init() which is great. gs_malloc_init initializes the ctx stuff and allocates memory with the allocatore gs_malloc_init created. later pcl wraps the allocater (gs_memory_chunk_wrap) (chunk allocator) then tries to free ctx stuff with the free procedure defined by the chunk allocator, not the original allocator, no joy finding this by the way... | 18:22.33 |
| | anyway the alloc and free with the different allocators is not great. | 18:23.14 |
| Robin_Watts | henrys: Ok, give me a moment to context switch here. | 18:23.35 |
| henrys | sure | 18:23.57 |
| Robin_Watts | You're saying that that's how it USED to work? Or that's how it works now with the language_switch branch ? | 18:24.45 |
| henrys | Robin_Watts: I don't know when this broke. Have you always freed the icc library directory as it is now? | 18:25.20 |
| Robin_Watts | henrys: In the language_switch branch, I don't expect pcl to work at all. | 18:25.45 |
| henrys | Robin_Watts: oh no I'm talking about what's in head now. | 18:26.06 |
| | golden | 18:26.11 |
| Robin_Watts | henrys: Ah, right. | 18:26.15 |
| | Let me swap back to that. | 18:26.20 |
| henrys | so I do ahve chrisl_away's changes | 18:26.22 |
| Robin_Watts | So we're in pl_alloc_init() ? | 18:27.25 |
| henrys | I brought up mvrhel_laptop because the crash happens with the ICC directories. | 18:27.34 |
| | Robin_Watts: well it just calls gs_alloc_init | 18:27.46 |
| | but yes starting in pl_alloc_init() | 18:28.10 |
| Robin_Watts | Right, that does sound broken. | 18:28.32 |
| | Nowt to do with me though :) | 18:28.40 |
| | From my 15 seconds thinking about this, I reckon that pl_alloc_init should store the gs_memory_t * it gets back from gs_malloc_init somewhere before it wraps it. | 18:30.07 |
| | This stuff may well be different in the language_switch branch because the 'frontend' passes every language it's own gs_memory_t, IIRC. | 18:31.02 |
| | OR, possibly better... the lib_ctx should store the memory pointer that it was created with inside it. | 18:31.54 |
| henrys | Robin_Watts: that more in line with what I was thinking... | 18:32.31 |
| Robin_Watts | The lib_ctx already stores the memory pointer inside it :) | 18:32.45 |
| | So, where is the free that's causing the problem again? | 18:33.36 |
| henrys | so why is gs_lib_ctx_set_icc_directory() not using it? | 18:33.50 |
| Robin_Watts | bug? | 18:34.18 |
| henrys | the free on line 73 gslibctx.c - I'm replacing the icc directory. | 18:34.42 |
| Robin_Watts | Yeah. | 18:35.23 |
| henrys | I didn't realize you stashed the mem pointer in the lib ctx. That might be an easy fix then? | 18:35.41 |
| Robin_Watts | I reckon we need: gs_memory_t *ctx_mem = p_ctx->memory; at the start of the function. | 18:35.46 |
| | then use ctx_mem instead of mem_gc->whatever | 18:36.06 |
| | Several functions in there probably need the same fix. | 18:36.18 |
| pipitas | I'm trying to build Ghostscript on an OSX system (Yosemite, 10.10.5 with lots of MacPorts packages) from current Git sources. | 18:36.29 |
| | To explain what the problem is, I'd need to paste about 50 lines into this IRC. Is that Ok, or do you prefer me to use a pastebin on the net? | 18:36.29 |
| Robin_Watts | pastebin please. | 18:36.39 |
| Robin_Watts | is being called. | 18:39.02 |
| henrys | Robin_Watts: well much less painful than I thought... | 18:39.11 |
| Robin_Watts | henrys: You've got enough to go on then? | 18:39.11 |
| | yeah :) | 18:39.14 |
| henrys | yup I'm good | 18:39.18 |
| pipitas | Can one of you please advice me on my GS build problem on OSX concerning "libiconv" ? Details here: http://pastebin.com/WwQxa2c6 | 18:45.55 |
| pipitas1 | hates it when his notebook crashes due to https://www.apple.com/support/macbookpro-videoissues/ | 18:54.20 |
| Robin_Watts | --without-iconv ? | 19:18.31 |
| | but that sounds like something chrisl should know about. I'm sure he'll look when he returns tomorrow. | 19:19.14 |
| sebras | tor8 (for the logs): I think I adressed all the things we mentioned here http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commit;h=80bc5d4e39253a8d3e999213d060cf12925d4a6a and I also added the missing patches and tidied thirdparty/jpegxr to use ITU-T as author and use correct authordates. it's here http://git.ghostscript.com/?p=user/sebras/thirdparty/jpegxr.git;a=summary and in my repo for you to copy if you so wish. | 19:28.38 |
| | tor8: of course I verified that this version renders to the same md5sums as before. | 19:29.47 |
| mvrhel_laptop | fredross-perry, Robin_Watts so there is a file that has an issue? | 19:53.43 |
| pipitas1 | Robin_Watts: I tried with (documented) "--with-libiconv=none" too. But same result. That should be equivalent to "âwithout-iconv", no? | 19:53.47 |
| | chrisl: if you return tomorrow and I'm not online: I'll look up in the logs later what has been said. | 19:55.10 |
| fredross-perry | mvrhel_laptop: Robin_Watts: try Altona.Page_3.2002-09-27.pdf | 19:59.51 |
| chrisl_t530 | Oh, pipitas is gone already? | 20:03.10 |
| | pipitas: with the current code, the option is "--with-libiconv=no"and that works - neither openprinting devices gets built | 20:08.00 |
| | That did not always work correctly, but I cannot remember in which release I fixed it - it was a while back, though | 20:08.48 |
| pipitas | chrisl_t530: I'll try that, thanks. | 20:11.07 |
| chrisl_t530 | pipitas: if that still doesn't work, you can open Makefile and search for "$(DD)oprp.dev" and "$(DD)opvp.dev" and delete those strings - and let me know, so I can dig into it a bit more | 20:14.43 |
| pipitas | chrisl_t530: Yes, "--with-libiconv=no" does get the build to work. No more error message after "make clean". | 20:17.08 |
| chrisl_t530 | Cool | 20:17.17 |
| pipitas | chrisl_t530: Thx a lot! | 20:17.28 |
| chrisl_t530 | No problem | 20:17.33 |
| pipitas | chrisl_t530: About the "oprp" and "opvp" strings â I had searched for these already a few weeks ago but at the time couldnt locate them. Maybe I was too dumb/tired⦠| 20:19.38 |
| mvrhel_laptop | fredross-perry: where is that file located | 20:50.13 |
| | I dont have it here | 20:50.17 |
| fredross-perry | iâll email it to you. But I think itâs on casper somewhere. | 21:02.34 |
| Robin_Watts | mvrhel_laptop: /home/support/150/Altona.Page_3.2002-09-27.pdf | 22:09.51 |
| | Forward 1 day (to 2015/08/27)>>> | |
IRC Logs