| | <<<Back 1 day (to 2015/10/20) | 20151021 |
| kens | tcarmen it sounds like you haven't specified the printer name properly. YOu would need to show us a complete example command line before we could even attempt to help. You should aslo make sure you are using a reasonably up to date version of Ghostscript. From comments on Stack Overflow it seems thsi is working ofr others. | 07:52.13 |
| | faLUICE (for the logs) depends what you mean by crop. You can certainly alter the CropBox. | 07:52.52 |
| | yitzchok (should he red the logs) We are willing to look into your problem. The bug report you point to is caused by a bug in the PostScript ineterpreter in the Brother printers, whch we worked around. You should first try the current version (9.18) with your file and if that continues to fail contact us and we will work with you to try and resolve the problem. Warning, ths *will* mean sending lots of pages to your printer and r | 07:55.29 |
| | eporting the results back to us....... | 07:55.29 |
| tomty89 | chrisl: hi have you seen this bug report http://bugs.ghostscript.com/show_bug.cgi?id=696263 ? do you think this is a bug of the fonts or just a defect of LO? | 11:40.49 |
| chrisl | tomty89: I suspect it is something about the way LO is embedding the font - whether it's an LO bug, or not, I'm not sure. | 11:42.35 |
| | tomty89: I have to say, having all the fonts in there is not very helpful :-( | 11:48.11 |
| tomty89 | chrisl: because it only happens to the fonts which get updated in the last commit, so i wonder if I can get some hint here on what exactly change in the commit might be related to this | 11:48.56 |
| | chrisl: that's why I listing all the fonts as well | 11:49.10 |
| chrisl | tomty89: it *looks* like the fonts that work have a differences array for the encoding, where the fonts that don't work do no not. Although the same fonts work with the previous versions, but it might be indicative of where the issue lies | 11:57.35 |
| | And the files aren't editable by Acrobat, FFS :-( | 11:59.03 |
| tomty89 | chrisl: but you mean the array of encoding did not change in the last update? | 11:59.15 |
| | chrisl: the one with problematic fonts or both? D: | 11:59.37 |
| chrisl | tomty89: the fonts should all be using StandardEncoding] | 12:03.04 |
| | Except Symbol and Dingbats, of course..... | 12:05.35 |
| tomty89 | hmm seems LO does have at least something to do with this. Firefox and Chromium seem to embed them without problem | 12:07.26 |
| chrisl | tomty89: actually, it seems that the libreoffice-old.pdf file contains a differences array for the Encoding of NimbusSanL-Reg whilst libreoffice.pdf does not - I'm guessing the problem is related to that | 12:15.05 |
| | Especially as the glyph names listed in the differences array are /agrave /egrave /igrave /ograve /ugrave | 12:16.23 |
| tomty89 | chrisl: i see. thanks for your help. i'll file a bug report to LO with these info | 12:17.37 |
| chrisl | tomty89: I confess, I am baffled as to how changing the font might have caused the change in behaviour..... | 12:18.31 |
| | Hmm, strange, LO embeds a CMap and never uses it..... clearly someone felt their PDFs were too small! | 12:31.36 |
| Robin_Watts | chrisl: You've seen LO, right? You know their approach to size :) | 12:32.31 |
| chrisl | Robin_Watts: True! | 12:33.11 |
| tomty89 | they do perform horribly on the size :S | 12:38.03 |
| | (and pretty much other aspect as well I guess) | 12:38.42 |
| chrisl | Well, writing unused objects into a PDF isn't a great start..... | 12:40.35 |
| | tomty89: if you want (and if I have time), if you create PDFs with just the one string in the one problem font (working PDF and a non-working one), I may be able to give a more concrete reply. | 13:04.27 |
| | For whatever reason, Acrobat cannot edit the ones attached to the bug, and whilst I could hack them down manually, it's just too time consuming from those starting points | 13:06.25 |
| tcarmen | kens: I'm using: -empty -dPrinted -dBATCH -dNOPAUSE -dNOSAFER -dNumCopies=1 -sDEVICE=mswinpr2 -sOutputFile="\\spool\Epson Test 2" For sOutputfile, I've tried "\\spool\printserver\Epson Test 2", "%printer%\\printserver\Epson Test 2" and a bunch of others. I ran across a really old bug mentioning a registry edit fix from ~2009, but don't think that's it, since everybody else isn't having this problem I'm probably not specifying the p | 13:12.42 |
| | rintserver queue correctly. Any ideas are appreciated. | 13:12.44 |
| kens | tcarmen, sorry I had to go and minister to a sick computer and missed your update | 14:16.40 |
| | Your -sOutputFile settings all look incorrect. Are you trying to print to a printer on a remote computer ? | 14:17.08 |
| tomty89 | chrisl: okay i've posted simpler pdfs on the bug report. btw i can open PDFs (the long ones) from LO with Acrobat Reader DC (15.009.20071), looks the same ways as they do in evince/gs | 14:20.56 |
| kens | chrisl looking at those simplified PDF file, the major difference seems to be that the 'working' file has an Encoding supplied like ths: | 14:36.12 |
| | << | 14:36.12 |
| | >> | 14:36.12 |
| | "<< | 14:36.30 |
| | " /Type /Encoding | 14:36.30 |
| | " /Differences [ 0 /agrave /egrave /igrave /ograve /ugrave ] | 14:36.30 |
| | ">> | 14:36.30 |
| | The non-working file has no Encoding and so uses the built-in encoding. Clearly that is not the encoding the applicaton thnks it is :-) | 14:37.01 |
| | Ths looks rather more like a bug in Libre Office than one for us | 14:37.17 |
| | Quickly checking the code points they are using, they are not assuming a StandardEncoding for the font. | 14:39.00 |
| | Looks like thjey are assumign the font is ISOLatin1Encoding, which I very much doubt it is | 14:40.23 |
| tomty89 | kens: any idea what changes in the fonts have triggered the omitting of that? coz the two PDFs are emitted by exactly the same version of LO but with two different commits of the fonts | 14:44.25 |
| kens | tomty89 : no idea at all, I think that's something you would have to aske the LibreOffice folks | 14:44.50 |
| tomty89 | kens: okay | 14:45.01 |
| kens | I could probably (eventually) work it out by repeatedly decompiling, modifying and recompiling the fonts, but that would take me a very long time. Someone at LO should be able to work it out much faster by debugging the source. Also, unless there is something unexpected about the fonts, the fact that they are assumign a font has an ISOLatin1Encoding is just wrong. You should never assume a font's encoding | 14:46.28 |
| kens | goes to fetch more coffee | 14:47.45 |
| tomty89 | kens: i see | 14:48.06 |
| kens | Of course, ths is all deduction based on what I see in the PDF file, I could easily be proven incorrect. | 14:51.59 |
| | But the 'working' PDF has character codes 01, 02, 03, 04, 05 whcihh matches the Encoding (1 -> agrave etc) | 14:52.30 |
| | While the non-working file has no ENcopding and character code 0xE0, 0xE8 etc, whch map to agrave and egrave in ISOLatin1Encoding, but to no character and Lslash in StandardEncoding (which is what the font most likely uses) | 14:53.27 |
| | WHich is why you see missing glyphs and a Lslash when you open the PDF | 14:53.46 |
| Robin_Watts | Washing machine just exploded. | 15:12.37 |
| kens | Literally ? Messy..... | 15:12.49 |
| henrys | Robin_Watts: in the new kitchen? | 15:16.23 |
| Robin_Watts | henrys: yeah. 37 days old. | 15:16.44 |
| | water and gravel everywhere. | 15:16.55 |
| henrys | gravel? | 15:17.03 |
| kens | concrete weight in a washing machine | 15:17.13 |
| | TO hold it down | 15:17.19 |
| Robin_Watts | I think one of the stabilising blocks in it has fragmented and taken out some plumbing. | 15:17.23 |
| henrys | oh lord that's terrible | 15:17.39 |
| Robin_Watts | Helen is... unhappy. | 15:17.51 |
| kens | thinks understatement of the century | 15:18.39 |
| henrys | chrisl: are you about? | 15:19.13 |
| mvrhel_laptop | ugh that stinks Robin_Watts | 15:20.59 |
| Robin_Watts | mvrhel_laptop: No, that'll be me if we have no washing machine for 2 weeks :) | 15:21.18 |
| mvrhel_laptop | ah still sense of humor after that | 15:21.40 |
| | wait this was a brand new washing machine? | 15:22.37 |
| Robin_Watts | Yup. | 15:22.42 |
| mvrhel_laptop | I would think that would be covered by some sort of warranty for damages | 15:22.55 |
| Robin_Watts | mvrhel_laptop: The kitchen is undamaged, thankfully. | 15:23.09 |
| mvrhel_laptop | oh good | 15:23.12 |
| Robin_Watts | (And amazingly, the guy who fitted the kitchen was here doing some last minute stuff as it happened) | 15:23.40 |
| henrys | chrisl: anyway just a minor bug in the build I'll just create a bug. | 15:24.47 |
| tcarmen | kens: Yes, I'm trying to send the output to a print queue on a Windows print server. | 15:25.22 |
| kens | tcarmen I believe you cannot do that, mswinpr2 only works with printers local to the machine it runs on | 15:25.41 |
| tcarmen | OK. that would explain quite a bit. Not sure if 8-) or 8-( | 15:26.02 |
| kens | Sorry but I believe its a fundamental limitation of the way the device works | 15:26.27 |
| tcarmen | Does it need to be actually plugged in to an LPT port or could it be a network printer that's setup locally with an IP address? | 15:27.20 |
| kens | I admit I am not certain | 15:27.36 |
| tcarmen | OK. I'll try it and see what happens. Thanks for your help. I've been beating on this for days. | 15:28.04 |
| kens | THe printer has ot be one you can point to on the current machine, but beyond that, I am unsure. Possibly as long as the driver is on the local machine it will spool to a networked printer via the print server | 15:28.15 |
| tcarmen | Oddly enough, when the "select printer" dialog pops up, and I pick a printer, mswinpr2 prints perfectly. It just can't seem to figure out what peintr I want, from the sOutputFile switch. | 15:28.45 |
| | peintr->printer | 15:28.58 |
| kens | Well, you cna't use a path in the OutptuFile | 15:29.12 |
| | SO %printer%\path\printer name doesn't work | 15:29.29 |
| tcarmen | Hmmm. OK. I'll see if there's some way I can make it look local. | 15:29.48 |
| kens | I thnk we use %printer% to enumeratge the local printerts and then match the following string wiht the named available print devices | 15:29.54 |
| tcarmen | how do you do that (where do you use %printer%)? | 15:30.25 |
| kens | SO if you have a locla pritner with that name it works, but I am unsure how you would go about specifying such a device in Windows | 15:30.30 |
| | -sOutputFile=%printer%PrinterName | 15:30.45 |
| tcarmen | OK, I'll try it! Thanks for the help! | 15:31.53 |
| kens | NP | 15:31.57 |
| chrisl | henrys: back now | 15:47.56 |
| tcarmen | kens: No joy changing the printer name, however I did go through the output drive list and found one called "epson", which works perfectly, since it's an epson printer. I had assumed since this was a Windows system, I needed mswinpr2, which is apparently not the case. Everything's working, and thanks again for your help. | 15:51.27 |
| kens | NP | 15:51.45 |
| | Glad its workign anyway | 15:51.52 |
| henrys | chrisl: maybe I should just ask what is a make incantation for a coverage build? I guess it works since marcos uses it. Setting XCFLAGS and LDFLAGS isn't quite right for me, putting libs before objects in ldt.tr and resulting in link order problems. | 15:52.04 |
| tcarmen | Me too. Been hoping my boss wouldn't walk by and ask "Why isn't it done yet?" | 15:52.16 |
| | 8-) | 15:52.20 |
| kens | These things are never as easy as you think they are going to be..... | 15:52.37 |
| tcarmen | No kidding. I've been doing this for 30 years and it's still never as easy as I expect. My favorite answer for "How long will it take" is "That's a good question." 8-) | 15:53.32 |
| kens | twice as long as you think, and for managament double the estimate again | 15:54.03 |
| tcarmen | 8-) | 15:54.09 |
| | Anyway, thanks again. Time for lunch. CU all later. | 15:54.21 |
| kens | bye | 15:54.29 |
| kens | hopes henrys wasn't listening to that last comment..... | 15:55.01 |
| chrisl | henrys: I would do "./autogen.sh CFLAGS="-fprofile-arcs -ftest-coverage" | 15:56.29 |
| henrys | chrisl: you do need the -lgcov as well and that seems to be the issue | 15:57.03 |
| chrisl | Hmm, not according to the gcov manual..... | 15:57.37 |
| henrys | yeah I don't know why it doesn't I get missing symbols without it and it works with it so... | 15:58.43 |
| | chrisl: I guess the more general issue is how you add an extra library on the command line.... XLDFLAGS gets set with the options before the objects, maybe XLDFLAGS should just be used for options and extra libraries should have another variable. | 16:00.38 |
| chrisl | XTRALIBS= | 16:01.01 |
| | so, make XTRALIBS=-lgcov | 16:01.20 |
| henrys | oh shit is that it, I was setting XLIBS stupid, thanks | 16:01.37 |
| | thanks chrisl | 16:03.49 |
| chrisl | I must admit, I think it is bonkers that the externally visible setting is "XTRALIBS" and the "internal" variable is "EXTRALIBS" - I'd have thought the more readable one would be used on the command line, but hey...... | 16:03.58 |
| kens | Night folks | 16:21.57 |
| mvrhel_laptop | henrys: so I have a fix for oxps. It just required a names space check beyond what ray had done. There is going to be content that we can not handle (for example the jpegxr images) at this time but the rest should work | 16:37.26 |
| | let me see if I can find or generate an example with a jpegxr image to see what happens.... | 16:39.48 |
| chrisl | mvrhel_laptop: gxps should consume jpegxr - if not, we could drop the PITA sources for it! | 16:44.38 |
| mvrhel_laptop | chrisl: oh really | 16:45.28 |
| | when was that added? xps does not have jpegxr | 16:45.48 |
| | if we have the lib to do it I will make sure it is working.... | 16:46.26 |
| tor8 | mvrhel_laptop: jpegxr is the same as hd-photo which is the same as windows media photo. just a new name for the same crap. | 16:46.29 |
| mvrhel_laptop | I think there are some diffs | 16:46.38 |
| chrisl | Well, it was added at the time we got the jpegxr sources in the repo.... quite a while ago | 16:46.39 |
| mvrhel_laptop | ok. well let me see what happens... | 16:47.01 |
| | I have some xps files that have hd photo. lets see if the windows print of those to oxps makes jpegxr content in the output | 16:48.50 |
| | well that is interesting. | 17:00.59 |
| | tor8: you are right, it is basically hd-photo | 17:02.18 |
| | hmm microsoft did release BSD licensed JPEG XR library | 17:03.13 |
| tor8 | mvrhel_laptop: we are using the reference implementation from ITU-T | 17:03.42 |
| mvrhel_laptop | ok | 17:03.48 |
| tor8 | mvrhel_laptop: microsoft's BSD code is beyond crap | 17:03.50 |
| mvrhel_laptop | I imagine... | 17:03.56 |
| tor8 | you're looking at >2k lines of boiler plate code just to start opening a file | 17:04.14 |
| mvrhel_laptop | that sounds typical | 17:04.25 |
| tor8 | the reference implementation is pretty shoddy as well, but at least it's got a somewhat usable interface | 17:04.45 |
| henrys | tor8: so you have that working (tested) in mupdf? | 17:06.26 |
| | tor8: or only compiling and running? | 17:07.01 |
| tor8 | henrys: we have it integrated and working in mupdf, but not on the main branch. | 17:07.46 |
| | I have not tried building it in windows, and I suspect that's where we'll run into trouble | 17:08.17 |
| | might have to compile that code as C++ ... it uses a lot of variable declarations that aren't at the top of the function. | 17:08.42 |
| Robin_Watts | tor8: Is there anything stopping us from fixing that in the code? (other than the effort involved?) | 17:10.54 |
| tor8 | no. | 17:11.06 |
| | but if we're going to start fixing that code, we're in for a big project :) | 17:11.20 |
| | and I'm not sure spending time on JPEG-XR is worth the effort | 17:11.39 |
| chrisl | The jpegxr code in ghostpdl should have all the in-line declarations sorted | 17:12.02 |
| Robin_Watts | chrisl: I think sebras has been working on the stuff in mupdf, fixing bugs etc. | 17:15.00 |
| | As such fixing the inline declarations in that might give us a better source tree. | 17:15.28 |
| tor8 | should be easy enough to merge the changes from ghostpdl with the changes sebras did for mupdf | 17:15.35 |
| Robin_Watts | ideal. | 17:15.43 |
| tor8 | they're both based off the same code drop from ITU-T, but I believe mupdf has a more recent version | 17:16.07 |
| henrys | mvrhel_laptop: I'm surprised how many vendors support jpegxr according to wikipedia... I'm not hopeful we can pass on the feature. | 17:19.14 |
| | mvrhel_laptop: we can also license it from leadtools | 17:19.26 |
| | mvrhel_laptop: nvm that last I misread something | 17:20.10 |
| mvrhel_laptop | ok there is something wrong | 17:22.23 |
| | created a high bit depth jpegxr image and printed out to both xps and oxps | 17:22.50 |
| | gs handled the xps one fine but not the oxps one | 17:23.04 |
| | also mupdf did not show either of them... | 17:23.41 |
| | oh I take it back | 17:25.57 |
| | gs did handle the oxps version. It just threw up a warning about an empty reference | 17:26.23 |
| | empty resource dictionary I mean | 17:26.48 |
| | ok so henrys I think we can close this bug. I will do a cluster test first though | 17:27.04 |
| henrys | mvrhel_laptop: are you certain you have a jpegxr image and not just jpeg? | 17:27.45 |
| | mvrhel_laptop: you are using the MS implementation not the jpeglib? | 17:28.00 |
| mvrhel_laptop | henrys: yes. I created it with a plug in for photoshop. | 17:28.25 |
| | I also looked at the xps and oxps content | 17:28.34 |
| | 128 bit RGB image | 17:29.17 |
| henrys | mvrhel_laptop: okay, I was thinking some quick breakpoints on the implementations api but that might be overkill, if you are pretty certain we are doing xr | 17:29.43 |
| mvrhel_laptop | henrys: the only concern/issue is this | 17:30.00 |
| henrys | mvrhel_laptop: of course you are only testing with RGB it does a lot more than that, right? | 17:32.13 |
| mvrhel_laptop | the windows print driver "saves" the image content in the oxps and xps file as a wdp extension. Now, for oxps the "best practice" is that it be a jxr extension. Let me pull it out of the xps file | 17:32.16 |
| | henrys: yes it does N-channel CMYK etc | 17:32.38 |
| tor8 | mvrhel_laptop: you'll need the tor/jpegxr branch if you want to test it with mupdf | 17:32.43 |
| mvrhel_laptop | tor8: ah ok | 17:33.10 |
| | henrys: I can test CMYK and n-channel | 17:33.59 |
| | let me do that | 17:34.05 |
| | but let me pull the image out of the oxps and see exactly what is there | 17:34.22 |
| | My question is, what, if any, are the differences between jpegxr and windows hd photo or what ever they call it | 17:34.51 |
| tor8 | mvrhel_laptop: I suspect it's just the list of supported pixel formats | 17:36.18 |
| | but I haven't been able to find a definitive list of differences | 17:36.34 |
| mvrhel_laptop | yes. this is not so well documented | 17:36.51 |
| sebras | tor8: mvrhel_laptop: I think the restriction in pixelformats is just limited by the xps spec, not by the format itself. so jpegxr is as far as I understand identical to hd photo. | 17:48.39 |
| mvrhel_laptop | ok. so yes we are using the jpegxr code. | 17:53.18 |
| | on that note let me do a cluster push and move on... | 17:53.32 |
| | hmm the visual studio project file is mucked up with respect to its paths and the jpeg stuff | 18:08.50 |
| | ok that is done. lunch time. bbiaw | 18:31.39 |
| | Forward 1 day (to 2015/10/22)>>> | |
IRC Logs