| <<<Back 1 day (to 2018/08/20) | 20180821 |
deekej | hello chrisl, you should hopefully receive latest version of URW fonts soon | 08:13.38 |
| they've made some small changes to positioning for OTF versions, so they should be similar to T1 versions | 08:14.09 |
chrisl | deekej: OKay, thanks. Do you know of any changes to the Type 1 versions? | 08:15.33 |
deekej | let me see | 08:15.44 |
| I can't find anything in my e-mails regarding Type 1. IIRC, all the complaints were about OTF looking different / not having same chars as Type 1 | 08:17.25 |
| so that's what we were trying to solve | 08:17.38 |
chrisl | Okay, thanks | 08:17.48 |
| I do wonder how the OTF versions can end up different to the Type 1 versions.... I find that rather worrying | 08:18.55 |
deekej | I can only guess | 08:19.06 |
| maybe they have seperate git branches for its development? | 08:19.29 |
chrisl | Well, that would be awful..... | 08:19.42 |
deekej | (no longer converting Type1 to OTF?) | 08:19.43 |
| or maybe the convert process is not so perfect | 08:20.02 |
chrisl | most designers retain the "original" format of their design tool(s), and then export to various font types from the same source | 08:20.52 |
| So there should never be Type 1 <-> OTF <-> TTF conversions happening | 08:21.22 |
deekej | hmm, I guess Juergen could answer that | 08:21.27 |
| I see | 08:21.39 |
chrisl | It's not that important. | 08:22.25 |
| Possibly the OTF exporting code is relatively new, especially populating the OTF tables (rather than the outlines, which out to be identical to the Type 1 outlines) | 08:24.27 |
deekej | kens, chrisl: hey guys, have you seen this? http://seclists.org/oss-sec/2018/q3/142 | 14:43.50 |
kens | Nope | 14:44.11 |
deekej | you probably have a batch of several CVEs coming your way | 14:44.30 |
kens | <sigh> | 14:44.39 |
deekej | I've just heard/read about it | 14:44.52 |
| the mail was published today on the oss-sec | 14:45.02 |
chrisl | I wouldn't mind so much if they'd ever come up with a "real* exploit in Postscript | 14:45.18 |
kens | I'm not sure what 'disabling coders' means in this context, but I can't think people will be happy with disabling PDF | 14:45.51 |
| It would also be nice if he'd tell us before announcing to the world, and be sure he's using *our* code, not some random version from a distro | 14:46.32 |
| But of course, Google doesn't do responisble disclosure, do they ? | 14:46.58 |
deekej | yeah, Google... and same for other companies as well :-/ | 14:47.43 |
| the irony is that when Google is informed about some CVEs, they often don't do anything about it for quite some time | 14:48.49 |
| at least what I've read | 14:48.54 |
NancyDurgin | He seems to be talking about issues from several years ago, so maybe they figure that was already disclosed long ago? | 14:49.57 |
kens | Couldn't really comment, not being into this kind of thing | 14:50.05 |
| But seriously, its annoying that he posts it to a random site instead of letting us know first. | 14:50.25 |
chrisl | Well, if someone actually reports these to us, I'll look at them | 14:50.34 |
deekej | he wrote there he plans to inform you... but... | 14:50.45 |
NancyDurgin | I can't figure out from context what "distribution" he is suggesting to modify "policy.xml" in. No context for me there. | 14:50.55 |
deekej | I agree who should let you know first | 14:50.57 |
kens | Right, *after* he publicly discloses them, is that responsible behaviour ? | 14:51.01 |
deekej | IMHO no | 14:51.10 |
| NancyDurgin: me neither | 14:51.18 |
| NancyDurgin: I'm not aware of that file be existing in our distro | 14:51.43 |
kens | NancyDurgin: yeah that was what I meant, I wondered what he expected peeople to disbale | 14:51.48 |
deekej | is checking | 14:51.48 |
NancyDurgin | he is talking about some other distro, not ghostscript. Just not sure what. | 14:52.15 |
kens | I assume he means the Linux distribtuins and packagers | 14:52.38 |
NancyDurgin | anyway now I see he refers to a bug from 2016 and then lists a bunch of new ones. | 14:52.41 |
chrisl | ImageMagick | 14:52.44 |
NancyDurgin | kens: Yeah, could be. | 14:52.45 |
chrisl | The trouble is, Postscript is a programming language, no one should be running random Postscript from untrusted sources, any more than they should be running random shell scripts from untrusted sources | 14:54.01 |
deekej | chrisl: agreed | 14:54.26 |
NancyDurgin | yeah seems to be linux distro-related | 14:54.27 |
chrisl | FWIW, the first "exploit" he lists there does not seem to work on gs 9.22 | 14:55.54 |
kens | I wouldn't be surprised if he is using random old versions. Many distributions (we know) do not keep up to date with our fixes. | 14:56.46 |
deekej | kens: let me check that for you :) | 14:57.17 |
NancyDurgin | anyway, it seems like his recommendation is "don't run untrusted postscript", so from a security POV he is arguably correct | 14:57.19 |
kens | As Chris says, we'll address anything that gets reporeted | 14:57.23 |
| NancyDurgin: I won't disagree with that | 14:57.51 |
mvrhel_laptop | kens: do you want to talk now? | 14:57.55 |
kens | mcrhe | 14:57.59 |
| yes sure | 14:58.00 |
| If you look in gsicc_cache.c | 14:58.16 |
| line 532 | 14:58.26 |
| There's a loop | 14:58.30 |
| Tht's cauing an infite loop for me | 14:58.45 |
| I have a file which uses *lots* of memory (> 2GB) and allocations start failing. | 14:59.05 |
| Shortly after that, this loop is entered, and never exits. | 14:59.16 |
mvrhel_laptop | hmm... | 14:59.17 |
kens | I 'suspect' that we have failed to kick off a thread or ssoemthing due to the memory allocation failures. | 14:59.36 |
| But in any event, there comment 'this is probably a fatal error. MV ???' looks like it shoudl be, to me | 14:59.58 |
| Or at least, we should not retry indefinitely | 15:00.07 |
mvrhel_laptop | ok. yes I think ray may have written this. | 15:00.26 |
| but hand me the file, and I can take a look | 15:00.35 |
kens | I don't thikn it will help you to see the file | 15:00.49 |
| Because you neeed to run it in my PDF interpreter :-) | 15:01.01 |
mvrhel_laptop | :) | 15:01.07 |
kens | The file is one of the collection that Henry made for me by grabbing all the PDF files from Bugzilla | 15:01.48 |
| It appears to be attached to bug #689153 | 15:02.06 |
mvrhel_laptop | so ray wrote this, this past febuary | 15:02.43 |
kens | Ah | 15:02.52 |
| The file is attached to that bug report, called 9322.pdf if you really want it | 15:03.10 |
| 4.8MB | 15:03.17 |
mvrhel_laptop | well if I can't duplicate the issue it is not going to be of any help | 15:03.33 |
kens | That's why I didn't ask you to look at it :-) | 15:03.53 |
mvrhel_laptop | yes, and I agree with you | 15:04.04 |
| I am not sure what to do... | 15:04.09 |
kens | But if I'm right, potentially we can end up in here other ways, even if it is rare. | 15:04.10 |
mvrhel_laptop | yes | 15:04.16 |
kens | I'd add a maximum number of retries, and fail with an error if exceeded | 15:04.31 |
mvrhel_laptop | ok, I will do that | 15:04.47 |
kens | Thanks | 15:04.52 |
mvrhel_laptop | Thanks for pointing this out kens | 15:05.03 |
kens | Well, it was kind of obvious when my test script locked up.... | 15:05.20 |
| Oh policy.xml seems to be an IMageMagick thing | 15:26.29 |
chrisl | Yeh, I said that..... | 15:28.23 |
kens | Oh sorry, I missed it in the conversation | 15:28.35 |
moriarty | hey folks | 16:52.24 |
chrisl | Hi | 17:12.21 |
ghostbot | Welcome to #ghostscript. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. If you are looking for help or infomation about MuPDF, try the new #mupdf channel. | 17:12.21 |
moriarty | hey chrisl, do you have any experience with geospatial pdfs by any chance? | 17:14.56 |
chrisl | Nope | 17:15.40 |
moriarty | awh | 17:16.09 |
chrisl | IIRC, that's metadata, not directly to do with the marking operations | 17:16.41 |
moriarty | why are PDFs slow with ever increasing computer speeds? | 17:16.47 |
chrisl | Mostly because they are badly written | 17:17.02 |
moriarty | chrisl, by marking operations, you mean? | 17:17.06 |
chrisl | operations that make marks | 17:17.16 |
moriarty | like annotations? | 17:17.30 |
chrisl | Lines, fills, glyphs, images..... | 17:17.47 |
| The stuff that PDF was really meant to do | 17:18.17 |
moriarty | and they get compressed as a single layer afterwards? | 17:18.17 |
| or are they still within their own layers? | 17:18.26 |
chrisl | PDF doesn't have layers | 17:18.36 |
moriarty | i see | 17:18.38 |
| if PDF don't have layers, why is it possible to unmask redacted text in a PDF? | 17:18.55 |
| it almost feels like the redacting is a layer | 17:19.05 |
chrisl | Well first, if it's *properly* redacted, it isn't possible..... | 17:19.30 |
moriarty | sure, but i'm more curious about how that's possible if PDFs don't have layers | 17:19.50 |
| i would imagine a layerless file to just contain a single piece of information in that same spot of the PDF | 17:20.10 |
chrisl | Secondly, marking operations are z -ordered - so if you draw a fill over some text, then remove the fill, the text reappears | 17:20.14 |
moriarty | and not multiple conflicts | 17:20.16 |
| i see | 17:20.21 |
| z-ordered sounds suspiciously similar to layers to me | 17:20.38 |
chrisl | Well, if you mean each and every mark on the page is it's own layer, then I suppose so | 17:21.02 |
moriarty | thanks for that insight | 17:21.24 |
| so when you say they are badly written in terms of performance, are you referring to the PDF file or the reader? | 17:21.38 |
chrisl | The PDF file | 17:21.45 |
moriarty | are PDF creators capable of optimising badly written PDF files? | 17:22.17 |
chrisl | Well, PDF creators are generally creating the bad PDFs.... | 17:23.03 |
moriarty | i see | 17:24.35 |
| if only there was a one-click function that optimises poorly written PDF files within PDF creators much like how you can do the same for graphics files | 17:25.10 |
| i would definitely love to batch process all my slow PDFs | 17:25.23 |
chrisl | A widely encountered example are the PDFs produced by Cairo. Cairo always adds transparency content to the PDF, even if there are no objects with transparency - the consumer cannot easily tell (in certain cases) the transparency operations are pointless, so is forced to do all the blending calculations, even thought there is no visible effect | 17:26.04 |
moriarty | chrisl, are there decent PDF creators that can prune off unnecessary channels like transparency? | 17:28.14 |
chrisl | Not that I'm aware of, sorry | 17:28.46 |
| Many people do use Ghostscript with its pdfwrite device to "optimise" or "normalize" PDFs, but it's not the intended use, doesn't always work, and has side effects which not be desirable | 17:29.01 |
moriarty | i see | 17:30.35 |
| does Ghostscript have georeferencing capabilities or is that only an Adobe Acrobat thing? | 17:30.52 |
chrisl | Ghostscript does not - we don't really deal with any interactive features, since our primary target is printing | 17:32.32 |
| And with pdfwrite, one of the "side effects" I mentioned earlier would probably be stripping of the geospacial metadata - but I can't say that for sure | 17:33.25 |
moriarty | ah | 17:33.26 |
| what would be the definition of an interactive feature? | 17:33.47 |
| from my perspective georeferences are pretty passive features, they don't require any user interaction | 17:34.16 |
| ouch, stripping of metadata | 17:34.36 |
chrisl | Well, what do you do with the geospatial data? | 17:34.58 |
| As I understood it it, for example, allows you to associate coordinates with a map - so you could click on the map, and see the coordinates | 17:35.49 |
moriarty | yep, or you don't click on it, but it allows you to see where you are in reference to the PDF | 17:36.25 |
| e.g. an icon representing your position on the PDF | 17:36.38 |
chrisl | Either way, that's hard to do on paper! | 17:36.50 |
moriarty | and the PDF is references by a minimum of three geographic points | 17:36.55 |
| lol | 17:36.58 |
| printing would come in very handy | 17:37.05 |
| most electronic mapping devices tend to run the risk of running out of battery in the wild | 17:37.21 |
| so outdoor folks tend to print a paper copy to use with their compasses in the event that occurs | 17:37.37 |
chrisl | pdfwrite is designed to maintain the visual content of the input file, but it creates an entirely new PDF - it does not preserve any structure from the original | 17:38.32 |
| moriarty: Sorry, I'm going to have to go.... | 17:41.41 |
moriarty | chrisl, thanks for all your pointers | 17:49.14 |
| i appreciate it | 17:49.17 |
kens | mor | 18:09.11 |
| Forward 1 day (to 2018/08/22)>>> | |