| | <<<Back 1 day (to 2016/01/04) | 20160105 |
| Robin_Watts | I think the cluster is a bit behind in it's warning checking :) I fear I may have overloaded it a bit. | 01:12.44 |
| mvrhel_laptop | ok. I think I have this && || mess simplified to make a bit more sense | 01:47.18 |
| | I will cluster test later tonight | 01:47.39 |
| | dinner time now | 01:47.43 |
| | HenryStiles: fixed the confusing logic statement and got a progression in the process | 05:08.53 |
| | done for the night. tomorrow I am going to get back to mupdf | 05:09.19 |
| aleray | Hi, I'd like to add crop marks to a pdf document. I was wondering if I could just superimpose crop marks drawn in an illustration programm by hand? | 09:27.05 |
| chrisl | As in just add some hairline marks to the page? | 09:28.21 |
| aleray | chrisl, yes this is what I'd like to do | 09:29.26 |
| chrisl | Well, "probably" and "sort of" - if you use Ghostscript, you won't be modifying the PDF, you'll be creating a new PDF that visually resembles the existing one. And you need to know enough Postscipt to do the drawing | 09:31.16 |
| aleray | chrisl, I was thinking of using a layout program like scribus to make a blank page at the right size and export it to PDF. Then superimpose that PDF over my document | 10:17.01 |
| | then I would probably need to set the trimbox "by hand" using postscript and ghostscript | 10:17.41 |
| chrisl | aleray: that won't work as the gs PDF interpreter will both eject and erase the page for the new PDF file | 12:01.39 |
| | aleray: something very similar to what you want is covered here: http://stackoverflow.com/questions/12243044/is-it-possible-in-ghostscript-to-add-watermark-to-every-page-in-pdf | 12:11.40 |
| Robin_Watts | Aha , the warnings checker has caught up to only be 19 commits behind. | 12:17.13 |
| tor8 | Robin_Watts: several commits on tor/master for review (and possibly discussion) | 12:43.43 |
| Robin_Watts | tor8: will look in just a mo. | 12:43.55 |
| tor8 | I've also bashed tor/jni into implementing a tiny tiny tiny subset of the device interface to call devices implemented in java | 12:44.29 |
| | passing stroke states and colors ... ick. java's insistence of passing everything as objects on the heap is going to be painful ... allocate a new object for ever single color passed :/ | 12:45.19 |
| Robin_Watts | tor8: yeah. I've gone through all that pain already. | 12:46.09 |
| tor8 | I'm thinking more of the pain for all the poor java programmers who have to use this language... :) | 12:46.43 |
| aleray | chrisl, thank | 12:48.12 |
| | brb | 12:48.15 |
| Robin_Watts | tor8: So, we never do kerning? | 12:52.21 |
| | We are going to need to rethink layout a bit when we come to do bidirectional text. | 12:53.16 |
| | For the strtod one, why are we holding n, v and d as floats when they are all ints ? | 12:54.41 |
| Robin_Watts | bets 3 conversions of int to float will be cheaper than multiple "* 10 +" operations. | 12:55.38 |
| | And, can't we call it strtof ? | 12:56.01 |
| | fz_strtof ? | 12:56.14 |
| | fz_css_strtof even. | 12:56.24 |
| tor8 | Robin_Watts: ah yes, strtof it should be | 12:57.18 |
| | floats to reduce the amount of typecasting needed, but you're right they could be ints up to the end | 12:58.51 |
| Robin_Watts | Annotations are fz things. | 12:59.52 |
| tor8 | yes, but the actual details are pdf things | 13:00.07 |
| Robin_Watts | So... how can we have the 'types' of Annotations being pdf things ? | 13:00.07 |
| tor8 | I'm still not convinced about that commit | 13:00.16 |
| | a fz_annot has no type, it's just a wrapper to let pdf-ignorant read-only viewers look at them | 13:00.51 |
| Robin_Watts | My preference would be for fz_annots to all have types. | 13:01.28 |
| | and certain types will only occur/can only be created in certain file types. | 13:01.53 |
| tor8 | Robin_Watts: the list of types is very pdf specific though, and I don't expect to see any code other than the pdf editing code to use the enums | 13:02.43 |
| Robin_Watts | Until we add support for a new format that also does annotation editing. | 13:03.15 |
| tor8 | there certainly is no such code today | 13:03.15 |
| | in which case we'll probably need to redesign a whole slew of other code as well... | 13:03.32 |
| | ... or we add annotation to all document types using a separate file to store them in our own format | 13:04.08 |
| Robin_Watts | The purpose of having a divorce between the document format handlers and the app side is so that people can code without knowledge of the underlying capabilities of each format. | 13:04.36 |
| | tor8: Right, that would be another case where we want the divorce. | 13:04.56 |
| tor8 | I agree. in terms of our current code that divorce only exists on the plain reader side though. | 13:05.09 |
| Robin_Watts | We could reasonably have fz calls to ask about the capabilities of the format. | 13:05.24 |
| tor8 | once you get into interactivity, digital signatures, forms, etc we're exposing the glorious guts of pdf | 13:05.33 |
| | I'm hoping to change that this year; at least for form filling | 13:06.04 |
| Robin_Watts | (SOT has similar issues. There are still places where we say "oh, it's an excel file, so we should do xxxx" where really we want to say "it's got capability 'SPREADSHEET' so we should do"... | 13:06.23 |
| | tor8: The trick is to expose capabilities, without exposing the actual entrails. | 13:06.57 |
| | and having the types at the top level is the right way to go for that, I reckon. | 13:07.27 |
| tor8 | but I think we're going to be doing a disservice by pretending that fz_document and fz_pages can be edited... | 13:07.30 |
| | or we should enforce strict read-only document types | 13:07.40 |
| Robin_Watts | (or at least, pushing the types back down is a retrograde step) | 13:07.53 |
| tor8 | I've seen people on stackoverflow entertain the idea of copying a fz_page from one XPS document into a PDF fz_document and saving it | 13:08.05 |
| Robin_Watts | tor8: We have an "editing" capability. | 13:08.12 |
| | tor8: That's what the pdf-device would be for. | 13:08.42 |
| tor8 | but it's not finished... | 13:17.48 |
| | and all the annotation and form filling requires using pdf.h, pdf_document and calling pdf_specifics | 13:18.07 |
| | Robin_Watts: updated commits on tor/master | 13:22.27 |
| | Robin_Watts: to answer your previous question: no, we don't do any kerning | 13:22.46 |
| | our embedded fonts don't have kerning tables | 13:22.52 |
| | and modern kerning tables all use fancy opentype tables which freetype doesn't support | 13:23.07 |
| | and yes, bidi layout is going to be a pain | 13:23.25 |
| | chrisl: oh my god, the indentation in jbig2dec is completely bonkers. | 13:54.57 |
| | mixed tabs and spaces with no consistency about indentation depth or tab stop size anywhere | 13:55.15 |
| chrisl | tor8: excuse me while I pretend to be shocked....... | 13:56.13 |
| tor8 | shailesh really did a bang up job there... :/ | 13:57.40 |
| chrisl | I'm not sure it was that good before | 13:59.22 |
| | IIRC, it doesn't follow the (alleged) gs coding style | 14:00.34 |
| tor8 | how about I just run the whole shebang through gnu indent with the gs coding style options? | 14:01.47 |
| chrisl | That would be my preference - if it works | 14:02.19 |
| tor8 | the gnu indent thing mixes tabs and spaces | 14:02.38 |
| | astyle --style=kr is probably close enough?L | 14:02.45 |
| chrisl | I think you can prevent indent from using tabs | 14:03.12 |
| tor8 | yeah, only diff between gs coding style with gnu indent and astyle k&r is where the opening brace goes on enums and structs | 14:03.47 |
| chrisl | indent has a fairly bewildering array of options | 14:04.58 |
| tor8 | and they're not followed | 14:10.01 |
| | -cli4 is in the options, but the code in gs uses -cli0 (case label indent) | 14:10.15 |
| | or, well, gs uses a mixture :) | 14:10.50 |
| chrisl | We could really do with putting gs through indent, but IIRC, there's quite a few places in the gs code where indent gets confused | 14:12.45 |
| tor8 | yeah, the macros are bound to get it terminally confused | 14:22.41 |
| chrisl | Especially where you have opening and closing brackets in separate macros and nonsense like that :-( | 14:23.32 |
| tor8 | chrisl: ghostpdl tor/master has a reindent of jbig2dec and an update to C-style.htm if you care to review | 14:24.54 |
| chrisl | tor8: I lack the OCD-ness to trek through all the changes in detail, but at a glance, it looks considerably more consistent. which is good. | 14:28.24 |
| | tor8: but you could correct the commit message..... | 14:29.11 |
| tor8 | chrisl: oops. | 14:30.16 |
| | and I think I'll leave some of the big fat tables in jbig2_huffman.c unindented | 14:30.31 |
| chrisl | tor8: I'd be tempted to leave them because, a) they'll never be easy to read, regardless of what we do with them, and b) if we ever hit the code again with indent, it'll be fewer diffs to cope with next time | 14:32.22 |
| tor8 | chrisl: fair enough | 14:33.18 |
| chrisl | tor8: I'm a bit surprised at the "for loop has empty body" thing though - given that's a fairly well used thing in the wide world - no issue with your commit, but I think the compiler warning is dumb...... | 14:50.45 |
| tor8 | the compiler warning is when it's at the end of a line, if I put it on a separate line the compiler doesn't warn | 14:51.09 |
| chrisl | I suppose I can see the point... sort of | 14:52.01 |
| tor8 | gnu indent put the semicolon right back at the end | 14:52.35 |
| Robin_Watts | chrisl: Yeah, I've been changing stuff from for (...;...;...); to for (...;...;...)\n{} | 14:52.37 |
| lawrence615 | Hello everyone, I am using mupdf in my android app;it is working fine but have one problem...minifying the size of the library. Apparently the total size of the app has increased by significantly. From 3.2mb to 12mb after adding the library. I am using Android Studio and I added the library as a module | 14:56.02 |
| | Any help will be much appreciated | 14:56.19 |
| Robin_Watts | lawrence615: What fonts/CMAPs are you bundling in? | 14:56.37 |
| lawrence615 | I have Roboto-Medium.ttf and Roboto-Regular.ttf | 14:57.57 |
| Robin_Watts | lawrence615: So, you've altered the tables in generated? | 14:58.59 |
| tor8 | lawrence615: if you are sure you will NEVER need to support chinese, japanese or korean documents you can build the library with -DNOCJK | 15:00.36 |
| | if you want to support CJK documents, but only if they embed fonts, -DNOCJKFONT is a way to reduce the size a bit but it'll still cause trouble for those languages | 15:01.22 |
| | -DNOCJKFULL will embed a smaller CJK font, which will save you about a megabyte in total | 15:02.07 |
| lawrence615 | No, I did not alter anything. I cloned this repo from github then imported the lib https://github.com/tekinarslan/AndroidPdfViewer | 15:03.52 |
| Robin_Watts | lawrence615: OK, so the lib contains all the CMAPs, plus the base 14 fonts, plus a CJKV fallback etc. | 15:04.39 |
| | If you're wanting to view any PDF that you find in the wild, then you probably need all that stuff. | 15:05.11 |
| lawrence615 | @tor8, I am sure will not need the support of Chinese, Japanese and Korean....but how do I build? | 15:05.13 |
| Robin_Watts | If you're wanting to just view files that you create, then it can all be omitted, by simply ensuring that the PDFs use embedded fonts. | 15:05.36 |
| tor8 | lawrence615: you'll need to build the mupdf library from source | 15:05.56 |
| | and add -DNOCJK to the compiler flags | 15:06.24 |
| | editn platform/android/jni/Core.mk and add a line LOCAL_CFLAGS += -DNOCJK near where the other such lines are | 15:07.12 |
| lawrence615 | @tor8 I have built the library from source and added that line near LOCAL_CFLAGS += -DHAVE_OPENSSL | 15:10.54 |
| Robin_Watts | lawrence615: Do you need an openssl build? | 15:12.01 |
| | Unless you're doing digital signature stuff, you don't. | 15:12.13 |
| chrisl | Doesn't it get used for decryption? | 15:12.40 |
| Robin_Watts | Nope. | 15:13.52 |
| chrisl | Goodo.... | 15:14.14 |
| lawrence615 | @Robin_Watts do I remove it? Because that's how the original Core.mk is. I have not touched anything else | 15:14.20 |
| Robin_Watts | lawrence615: The original Core.mk is designed to build our app, which includes the ability to check signatures. | 15:17.56 |
| | If you remove it, then it *should* degrade nicely. | 15:18.13 |
| | (If it doesn't, let us know) | 15:18.30 |
| lawrence615 | Okay...I am in the process of finalizing the building..I did not have ndk so am installing it now then continue. I am following these steps http://mupdf.com/docs/how-to-build-mupdf-for-android | 15:21.19 |
| grossberndts | Hello #ghostscript | 15:26.57 |
| Robin_Watts | grossberndts: Hello. | 15:27.25 |
| grossberndts | One of our webservers was brought down this morning by running out of diskspace very quickly due to a spammed apache2/error.log with 700GB of "**** File has unbalanced q/Q operators (too many Q's) ****". This is a debian wheezy server running ghostscript "9.05~dfsg-6.3+deb7u2". | 15:36.06 |
| | It turned out this was due to a process trying to create a thumbnail image of a pdf: "gs -q -dBATCH -dMaxBitmap=50000000 -dNOPAUSE -sDEVICE=pnmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r72x72 -dFirstPage=1 -dLastPage=1 -sOutputFile=XXX -- YYY -c quit" | 15:36.22 |
| | I could reproduce it on a debian jessie server running 9.06~dfsg-2+deb8u1 too by executing "gs -o proper.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress programmheft_2016.pdf" The file is available at http://www.naturpark-rheinland.de/programmheft_2016.pdf Is this a bug that has been fixed upstream? | 15:36.31 |
| | All pdf viewers I tried had no problems displaying the file. | 15:37.24 |
| chrisl | Well, 9.16 does not throw any warnings or errors | 15:37.45 |
| | grossberndts: so, I'd guess it's been fixed | 15:39.00 |
| rayjj | btw, I'm going to fix the message for unbalanced q/Q's when there are too many q's (both conditions were saying "too many Q's") | 15:41.35 |
| grossberndts | ok, thanks. I'll try pinning 9.16~dfsg-2 from debian stretch for now. I guess there is no easy way to identify the exact issue to ask the debian maintainers to backport it at least to debian jessie? | 15:44.20 |
| chrisl | grossberndts: you can clone our repo and git bisect | 15:45.10 |
| | grossberndts: it is also possible that the problem is caused by the specifics of the debian packaging (although fairly unlikely) | 15:46.19 |
| rayjj | grossberndts: the actual "too many q's" condition can only occur once per page (it is issued after the page is processed) | 16:09.05 |
| grossberndts | for the given file it produced 700GB logs with that message over and over again | 16:10.55 |
| tor8 | mvrhel_laptop: I've looked over your pdf_create branch briefly, still need to test run it to see what comes out the other end :) | 16:10.57 |
| mvrhel_laptop | tor8: I have run it with a simple test file I can give you | 16:11.28 |
| tor8 | looking good so far, most of my notes are about font naming that's inconsistent with the rest of mupdf :) | 16:11.41 |
| | s/font/function/ | 16:11.47 |
| mvrhel_laptop | and a command line that includes an image and a font | 16:11.48 |
| grossberndts | sadly 9.16~dfsg-2 is not available as a backport to debian jessie so I can't verify it works there | 16:11.51 |
| mvrhel_laptop | tor8: ok yes please let me know about naming | 16:12.13 |
| chrisl | grossberndts: it would be surprising if that 700Gb came just from trying to run the file once | 16:12.15 |
| tor8 | mvrhel_laptop: my biggest question is regarding the first_width/last_width fields you added to fz_font | 16:12.18 |
| | but I need to sit down and read the code more closely there | 16:12.32 |
| mvrhel_laptop | tor8: I have to look at it again to remember. I was wrapped up in a clist/alphabits/soft mask gs bug for the last two weeks | 16:13.06 |
| | after I get this gxiscale.c code cleaned up a bit today I am going to get started again. | 16:13.26 |
| rayjj | the too many Q's condition has a check that is also supposed to only issue it once also (.Qwarning_issued is the flag used for that) | 16:13.31 |
| tor8 | the font_width table is not guaranteed to be used, it's only there for substitute fonts where we need to adjust the metrics | 16:13.34 |
| | it won't exist for XPS, for instance | 16:13.39 |
| mvrhel_laptop | tor8: I created the font width table | 16:13.54 |
| | so that I could write it out | 16:14.03 |
| | iirc | 16:14.08 |
| tor8 | aha | 16:14.11 |
| chrisl | rayjj: I actually thought it was once per "context" - like in a form, or type 1 pattern, but still shouldn't be that extreme | 16:14.13 |
| tor8 | mvrhel_laptop: ah yes, I see now. that all happens in ft_width_for_simple_table | 16:14.47 |
| mvrhel_laptop | and I also need to write out the first and last width value | 16:14.49 |
| | yes | 16:14.55 |
| chrisl | grossberndts: FWIW, *our* 9.05 release does not throw any errors or warnings | 16:15.04 |
| grossberndts | this is apparently not the first time an infinite loop occurrs with unbalanced q/Q: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714247 | 16:15.45 |
| rayjj | chrisl: the .Qwarning_issued is put into pdfdict, so that looks like it is trying to be once per file (the lifetime of pdfdict) | 16:15.52 |
| grossberndts | hm, okay... | 16:15.56 |
| tor8 | mvrhel_laptop: you've also left some dirty dirty dirty trailing whitespace in there... ;) | 16:16.41 |
| rayjj | grossberndts: you may want to get our 9.05 and diff the files Resource/Init/pdf*ps to see what debian may have done to our code | 16:17.24 |
| grossberndts | http://pastebin.com/htwMtX1d | 16:17.35 |
| tor8 | mvrhel_laptop: "git config apply.whitespace fix" in your mupdf workspace should fix that for the future | 16:17.41 |
| grossberndts | these two processes hogged two cpus and filled the disk | 16:17.52 |
| | Thanks, I'll try to have a look. | 16:18.24 |
| mvrhel_laptop | tor8: ok thanks. I will clean that up today. Then I will start working on making sure we reuse existing resources | 16:19.58 |
| rayjj | grossberndts: OK, so definitely *NOT* a gs issue since the repeated invocation of 'convert' and 'gs' is nothing we control | 16:20.03 |
| mvrhel_laptop | tor8: right now it would stick in multiple copies of the same image or font | 16:20.25 |
| | I need to change venues. bbiab | 16:20.42 |
| grossberndts | as mentioned above I can reproduce it using 'gs -o proper.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress programmheft_2016.pdf' with http://www.naturpark-rheinland.de/programmheft_2016.pdf | 16:21.45 |
| | ah, ok, gs is nothing you control? | 16:22.16 |
| Robin_Watts | grossberndts: gs is ours, yes. | 16:22.47 |
| chrisl | We don't control how and how often it's being called | 16:23.01 |
| | grossberndts: the file contains JPX encoded images - if I was forced to, I would guess the culprit would be the Jasper library | 16:23.10 |
| Robin_Watts | but the fact that someone repeatedly called convert (which calls gs) on a broken file again and again is not our fault. | 16:23.15 |
| rayjj | grossberndts: no, the invocation of gs is not under our control. Why there is something looping and invoking gs is a broken script somewhere outside gs | 16:23.46 |
| | chrisl: that's before we went to openjpeg ? | 16:24.32 |
| chrisl | rayjj: it's not before *we* went to openjpeg, but I'd bet Debian didn't change with us because it wasn't a shared library] | 16:25.18 |
| rayjj | grossberndts: you said you can reproduce "it" -- what are you able to reproduce? | 16:26.00 |
| grossberndts | that single call to 'gs -o proper.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress Programmheft_HIHO_2016_Titel.pdf > log.txt 2> err.txt' seems to create an endless loop. | 16:27.27 |
| | I killed the process after that single execution created a 2.5GB err.txt | 16:27.59 |
| | programmheft_2016.pdf === Programmheft_HIHO_2016_Titel.pdf | 16:28.23 |
| chrisl | 9.05 works fine here - no errors, no warnings - even forcing it to use Jasper | 16:28.46 |
| grossberndts | libjasper1 is version "1.900.1-debian1-2.4" | 16:30.40 |
| | so as I understand the issue does not exist in ghostscript itself because for rendering JPX you use a different library (openjpeg) to decode the image while debian still uses jasper? | 16:32.07 |
| chrisl | Well, as I can't reproduce the issue, even using Jasper, I can't be sure. *Something* between our release, and what Debian has packaged there has broken stuff | 16:33.05 |
| rayjj | grossberndts: I recommend getting the source release from us, building it *without* shared libs, then if you have a problem, let us know | 16:33.09 |
| | grossberndts: and if that build works without an error, compare the Resource/Init/pdf*.ps files between the two | 16:33.57 |
| grossberndts | How do I build without shared libs? | 16:36.25 |
| chrisl | Using the shared system jasper on my system, I *do* get an error - but not the one you report | 16:36.42 |
| grossberndts | **** Warning: File has insufficient data for an image. error: cannot decode code stream unable to decode JPX image data. **** Error reading a content stream. The page may be incomplete. **** File has unbalanced q/Q operators (too many Q's) **** | 16:37.05 |
| | the last line is repeated infinitely | 16:37.24 |
| chrisl | Yes, I get the "error: cannot decode code stream" and "unable to decode JPX image data." and "**** Warning: File has insufficient data for an image." a few times, but that's all | 16:37.54 |
| | And then "**** Error reading a content stream. The page may be incomplete." and finally "Error: /rangecheck in --run--" with a full Postscript style error | 16:38.59 |
| | So jasper is triggering the error, but not the infinite loop | 16:39.45 |
| grossberndts | my colleague changed some transparencies in that pdf and saved it making it 5MB instead of 1.3MB. that file produces only the errors you mention but no infinite loop | 16:40.11 |
| | he says he changed to transparencies of shadows from vector to bitmap. | 16:42.25 |
| chrisl | I don't see how that's relevant | 16:43.54 |
| grossberndts | with transparencies of shadows as vector => infinite loop of "File has unbalanced q/Q operators" - with shadows as bitmaps => just some warnings - that's why I thought it to be relevant | 16:45.31 |
| chrisl | But using the 9.05 release, the file works as it stands | 16:46.04 |
| grossberndts | I cloned the ghostscript repo, checked out branch 'gs905' and called 'make'. This leads to 'make -C main -f pcl6_gcc.mak pdl-product # build PCL and PCLXL. make[1]: Entering directory '/root/ghostscript/ghostpdl/main' pcl6_gcc.mak:186: ../config.mak: file not found make[1]: *** No rule to make target '../config.mak'. Schluss. make[1]: Leaving directory '/root/ghostscript/ghostpdl/main' Makefile:27: recipe for target 'p | 16:50.29 |
| chrisl | grossberndts: you need to cd into the gs directory, and run autogen.sh - you may also need to install some of the autotools | 16:51.15 |
| grossberndts | Is compiling. I guess that way I am not 'building it *without* shared libs'? | 16:54.12 |
| chrisl | grossberndts: to build with (important) shared libs, you need to take special action | 16:54.39 |
| grossberndts | now I have a lot of *.o and *.dev files in obj/ but how do I call gs now? | 17:00.38 |
| chrisl | grossberndts: the executable should be in the "bin" directory | 17:01.06 |
| grossberndts | ./gs -o proper.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress ~/Programmheft_HIHO_2016_Titel.pdf GPL Ghostscript 9.05 (2012-02-08) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 | 17:02.26 |
| | that worked without problems. | 17:02.38 |
| chrisl | As it did for me | 17:03.17 |
| | grossberndts: if you have the jasper .dev package installed, I can tell you how to build against that | 17:08.51 |
| grossberndts | I built 9.06 now since debian jessie comes with 9.06. This is the difference between ghostscript 9.06 original and debian http://pastebin.com/d2FGg5hb | 17:14.04 |
| | correcting: I *tried* to build 9.06: ./obj/ttpost.o: In function `load_post_names': ttpost.c:(.text+0xad): undefined reference to `FT_Stream_ReadShort' ttpost.c:(.text+0x1b1): undefined reference to `FT_Stream_ReadShort' ttpost.c:(.text+0x268): undefined reference to `FT_Stream_GetShort' collect2: error: ld returned 1 exit status base/unixlink.mak:54: recipe for target 'bin/gs' failed make: *** [bin/gs] Error 1 | 17:15.50 |
| chrisl | grossberndts: erm, did you "make clean" before building again? | 17:16.58 |
| grossberndts | uhm, no. sorry. been some time since I last compiled something... | 17:19.29 |
| | so I guess to compare its better to use 9.06 (which is compiling now) | 17:20.08 |
| | (unsurprisingly) works as well. I installed libjasper-dev (1.900.1-debian1-2.4) | 17:21.40 |
| | chrisl: how to build against it? | 17:21.59 |
| chrisl | grossberndts: I put the steps here: http://pastebin.com/GN9c6c2h | 17:22.26 |
| | grossberndts: doing that with 9.06, I still see it erroring out sensibly | 17:24.28 |
| grossberndts | http://pastebin.com/5GF5Cj7c | 17:25.54 |
| | no infinite loop | 17:26.12 |
| chrisl | Same here | 17:27.31 |
| grossberndts | rayjj: Differences between Resource/Init/pdf*.ps are there http://pastebin.com/d2FGg5hb | 17:28.45 |
| | any ideas how to proceed? | 17:30.14 |
| chrisl | Report it to Debian | 17:30.22 |
| grossberndts | ok | 17:30.45 |
| chrisl | If we patch your version to work, it'll only get zapped if Debian do an update | 17:31.09 |
| grossberndts | I guess so. I thought it might make it easier to be patched in time by finding out the culprit | 17:32.12 |
| chrisl | You could try changing you command line (assuming you are still running from the "gs/bin" directory): gs -I../Resource/Init -o proper.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress ~/Programmheft_HIHO_2016_Titel.pdf" and see if that works | 17:32.20 |
| grossberndts | That gives the same result as I pasted - so no infinite loop | 17:33.33 |
| chrisl | So that is he Debian executable using our Postscript resources | 17:34.03 |
| grossberndts | and not failing miserably anymore | 17:34.24 |
| | well, still failing, but no infinite loop | 17:34.37 |
| chrisl | So, what you could do is copy our resources to somewhere central like "/usr/local/gs/" for example. And then set the environment variable "GS_LIB" to point to that | 17:35.47 |
| | You want, for example: GS_LIB=/usr/local/gs/Resource/Init | 17:37.23 |
| grossberndts | so the problem is somewhere in http://pastebin.com/emSHcUFE (diff of Resource/Init/*) | 17:37.45 |
| chrisl | It seems so, yes | 17:38.06 |
| grossberndts | I just need Resource/Init in /usr/local/gs/? | 17:38.57 |
| chrisl | I suggest copying the entire Resource tree in there | 17:39.28 |
| grossberndts | ok. I'll try that tomorrow morning. Got to leave now. Thanks a LOT for all the help! | 17:40.21 |
| | I'll report a bug with debian tomorrow. | 17:40.43 |
| chrisl | And you *must* ensure that GS_LIB is defined in the environment *wherever* gs is called | 17:40.46 |
| | grossberndts: are jessie and wheezy still supported? | 17:41.15 |
| grossberndts | thought so. I'll research how to do that tomorrow | 17:41.20 |
| | jessie is current stable, wheezy oldstable, so yes | 17:41.37 |
| | AFAIK | 17:41.48 |
| chrisl | Current stable is using a 3+ year old gs release... hmmmm | 17:42.30 |
| grossberndts | stretch has 9.16 at least.. | 17:42.46 |
| | gotta go, sry. | 17:42.57 |
| chrisl | Bye! | 17:43.03 |
| | Forward 1 day (to 2016/01/06)>>> | |
IRC Logs