| | <<<Back 1 day (to 2012/08/05) | 2012/08/06 |
| chrisl | pipitas: thanks for updating the OSX build bug: I do (when I have spare time) keep checking for a proper fix, but so far, nothing has worked. | 07:41.19 |
| ray_laptop | Is chrisl back tomorrow ? (later today) | 07:45.56 |
| chrisl | ray_laptop: chrisl is back now..... | 07:46.09 |
| ray_laptop | I'd like to be able to participate in the decisions on what to include (or not) in the release (what to cherry pick) | 07:47.02 |
| | chrisl: have you had a look, and do you have an opinion ? | 07:47.23 |
| chrisl | ray_laptop: I've had a quick look - I'm just a *little* concerned about the makefile changes, at this stage........ | 07:48.03 |
| ray_laptop | since henrys doesn't start for a few hours yet, I want to wait for him, but possibly also marcos | 07:48.17 |
| chrisl | ray_laptop: I'll confess, I had completely forgotten about icclib (should have been removed before 9.05!), but JasPER I had in notes to remove after 9.06..... | 07:49.15 |
| ray_laptop | chrisl: I was mostly concerned that the fixes/improvements for planar devices (tiffsep and tiffsep1) made it in | 07:49.44 |
| | chrisl: I am _NOT_ concerned about having the icclib and jasper deprecation wait till later | 07:50.29 |
| chrisl | ray_laptop: I picked up Robin_Watts's MaxSpots changes, and Michael's update on the back of that - were there others? | 07:51.14 |
| ray_laptop | chrisl: tk__ was the one that pointed out iccliib | 07:51.19 |
| chrisl | ray_laptop: yeh, as I say, icclib just got pushed to the back of my mind - actually, we can probably remove lcms, now that we're all there with lcms2 | 07:52.27 |
| ray_laptop | chrisl: b40b8fd and a884b57b (mvrhel's) and 974ba5dd (Robin's performance improvenment) were the ones I was focused on. | 07:53.39 |
| | chrisl: I _did_ confirm an oob access when b40b8fd was not there (NOT a real world case) | 07:54.32 |
| | I have less invested in fe9465d (but kens may want to weigh in) | 07:55.43 |
| chrisl | ray_laptop: okay, I *thought* b40b8fd related to making the devicen structure dynamic, but from what you say, I'm going to pull it in | 07:56.09 |
| kens | ray_laptop : which one was that ? | 07:56.26 |
| ray_laptop | I'm not sure exactly when you did the 9.06 branch | 07:56.37 |
| chrisl | ray_laptop: I took the branch on Tuesday 31st July | 07:57.09 |
| ray_laptop | kens: that's the first part of the SHA for your patch (I think) | 07:57.11 |
| chrisl | kens: probably ps2write leaving a dictionary on the stack | 07:57.33 |
| kens | Hmm, doesn't come up in git search.... | 07:57.38 |
| | Oh that's not vital | 07:58.12 |
| | We never sadi you could encapsulate ps2write output | 07:58.21 |
| ray_laptop | chrisl: In that case, then alecher's patch 004aeab5 may be worth including | 07:58.25 |
| chrisl | ray_laptop: that's already in the release branch | 07:59.05 |
| ray_laptop | kens: I usually use command line git log (with an msys shell) then do /_____(when ____ is the SHA) | 07:59.40 |
| kens | ray_laptop : but then I#'d have to open msys.... | 08:00.12 |
| chrisl | kens: on the web i/face you can do, for example: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=fe9465d | 08:01.13 |
| kens | chrisl, yes I was trying to ue it, but the search wouldn't find the commit for me using the hash | 08:01.42 |
| | Didn't occur to me to put it in the URL | 08:01.51 |
| | Today's piece of learning done :-) | 08:02.07 |
| | chrisl can you spare me a minute ? | 08:04.59 |
| ray_laptop | kens: sorry -- I don't know why the search for that partial hash tag didn't work | 08:05.01 |
| chrisl | kens: sure.... | 08:05.13 |
| kens | ray_laptop : I've nver had any success with the search in git.ghostscript.com, it doesn't like me | 08:05.24 |
| | chrisl could you pick up the files in bug #693242 and try the PostScript files for me please ? | 08:05.44 |
| pipitas | chrisl: Let me know if I can help with some tests re. OSX builds. Should I close #695232 then, or do you want to keep it open as a reminder? | 08:06.03 |
| kens | My copy of Jaws is ignoring the /Orientation key in the page device dictionary | 08:06.08 |
| ray_laptop | well, it can't be biased against Scots or it would not have worked for chrisl ;-) | 08:06.27 |
| chrisl | pipitas: it's fine to have it closed, I won't forget - and thanks for the offer of help, I'll ping you if I ever make progress! | 08:07.06 |
| kens | chrisl I have a sneaky suspicion the PostScript is doing something different when the CTM is rotated. I see quite different results when rendering with GS and the only difference is the /Orientation | 08:07.12 |
| ray_laptop | (sorry, chrisl, if you don't have Scots background like kens and me) | 08:07.19 |
| kens | chrisl is as Scottish as me | 08:07.30 |
| ray_laptop | kens: I thought so. | 08:07.40 |
| chrisl | ray_laptop: born just outside Edinburgh! | 08:07.45 |
| sebras | Robin_Watts: oh, I thought it was only ghostbot and me here last night. :) | 08:07.58 |
| ray_laptop | kens: chrisl: I am < 50% Scots | 08:08.00 |
| kens | ray_laptop : I'm 100% Scots as far back as our family tree goes | 08:08.20 |
| ray_laptop | but have some of the blood | 08:08.25 |
| kens | We did have abranch with Russian connections because of the Jute trade | 08:08.47 |
| | A Great great Aunt is supposed to have fled the Bolsheviks across a frozen lake.... | 08:09.34 |
| | Morning tor8 | 08:10.23 |
| chrisl | kens: I'll check the files in a few minutes - I'm having a git fight right now :-( | 08:10.46 |
| kens | chrisl no rush, I'm just trying to shortcut my investgation :-) | 08:11.06 |
| | The PostScript is proving resistant to hacking | 08:11.21 |
| ray_laptop | I'm sure my father's "engineer" side (great-grandfather designed many bridges in Ohio and grandfather was an engineer from Univ of Ohio that went to the Sorbonne that worked on the Eifell Tower | 08:11.21 |
| | helped me to live up to the Scots engneer tradition | 08:12.02 |
| kens | :-) | 08:12.09 |
| ray_laptop | I admire "Scotty" on Star Trek ;-) | 08:13.09 |
| kens | The actor was Canadian as I recall :-) | 08:13.29 |
| ray_laptop | he's as machine (and not people) oriented as me ;-) | 08:13.38 |
| | kens: Scots claim the blood without regard for their residence | 08:14.25 |
| chrisl | My maternal grandfather was an RAF radio engineer - since every electronic thing he built/repaired that I remember exploded (literally!), I wonder how successfull his military service can have been! | 08:15.14 |
| ray_laptop | chrisl: only a couple of the early electronic (back in the tube/valve days) resulted in pyrotechnics (but > 0) | 08:16.56 |
| chrisl | ray_laptop: Yeh, I suspect it was the age of the transister that caused him trouble - it didn't make me feel any better when my tape player went bang, though! | 08:18.36 |
| ray_laptop | woriking on tube amps/TVs with the power on was the best way to diagnose things, but there were often 250+ V differentials between adjacent contacts | 08:18.38 |
| | I have to help get the kids to bed -- they've been up watching the Olympics... | 08:20.07 |
| | g'nite | 08:20.17 |
| kens | THat's pretty late, what event were you watching ? | 08:20.22 |
| | night ray_laptop | 08:20.28 |
| chrisl | g'nite Ray.... | 08:20.29 |
| ray_laptop | bye, chrisl | 08:20.36 |
| | I hope we can discuss the release tomorrow | 08:20.55 |
| chrisl | kens: so, what did you want me to do with the Bug 693242 files? | 08:29.30 |
| | coffee beckons, back in a sec..... | 08:37.28 |
| kens | chrisl can you render them please ? On Jaws and ideally on HQN too if you can do so easily. The 'red' dashed line renders differently to me on the two files with GS. | 08:38.05 |
| | My problem is that the version of Jaws I'm using seems to ignore the /Orientation key in the page device dictionary and renders both 'landscape on portrait media' | 08:38.36 |
| tor8 | morning kens | 08:42.58 |
| chrisl | kens: IIRC, the example Jaws devices only honour Orientation for "roll-fed" devices..... | 08:43.16 |
| kens | chrisl that's probably my problem, I'll change the setup | 08:43.33 |
| chrisl | And I will try to remember the magic runes to get HQN to work..... | 08:43.57 |
| kens | Aha! | 08:47.05 |
| | And indeed I see exactly the same kind of rendering diffs with Jaws | 08:47.16 |
| | I believe I may even know why, and it demonstrates that Distiller is wrong, even though its what the customer 'expects' :-) | 08:47.45 |
| chrisl | Yes. I assume whatever sets up the line dash is doing something silly with the matrix | 08:47.59 |
| kens | Its not really a dashed line I don't think, its using a bitmap | 08:48.14 |
| chrisl | Oh, ick.... | 08:48.28 |
| kens | Yep | 08:48.32 |
| | And it seems to be assuming that the bitmap runs in a particular direction, so it just repeats it (its one pixel wide I think) | 08:48.58 |
| | Of course if you rotate teh page the sense of horizontal and vertical are also rotated | 08:49.19 |
| chrisl | I wonder if this is because Distiller just passes the orientation value through the output, and doesn't actually "apply" it? | 08:49.43 |
| kens | chrisl I'm fairly sure this is the case, yes. | 08:50.02 |
| | Now I just have to finish decoding the 'pfbf' procedure and concoct an explanation for the customer. | 08:50.58 |
| | I do not think they will like it mind you. | 08:51.14 |
| chrisl | Have you checked the various PDF outputs in viewers other than Acrobat? | 08:51.14 |
| kens | chrisl yes | 08:51.26 |
| | The trouble is ours is 'correct' when compared against rendered output. | 08:51.45 |
| | Distiller is wrong, but its what the customer thinks 'ought' to happen. | 08:52.05 |
| | However, I think that the customer has added the /Orientation themselves *after* the PostScript was produced. | 08:52.58 |
| | The Windows PS driver has produced PostScript which works just fine, but depends on the printer being the orientation it has been told. | 08:53.37 |
| chrisl | Huh, Evince doesn't even show dashed lines - all gray | 08:53.43 |
| kens | Altering the Orientation just doesn't work in this case. | 08:53.44 |
| | That's pretty poor from Evince..... | 08:54.06 |
| chrisl | I guess it's anti-aliasing | 08:54.32 |
| kens | Oh, that could be. | 08:54.41 |
| chrisl | Another reason for me to dislike indiscriminate anti-aliasing! | 08:55.15 |
| sebras | tor8: I updated sebras/master with another patch. | 08:59.42 |
| Robin_Watts | chrisl: "Stuff" ? | 09:34.36 |
| | So, we've successfully invaded Mars. | 09:43.50 |
| kens | TO answer the question 'Is there life on Mars ?' :-) | 09:44.10 |
| sebras | Robin_Watts: no, we've invaded the neighbours yard, as you so aptly put it some time ago. :) | 09:44.52 |
| Robin_Watts | I do hope Curiosity is playing "We come in peace. Take me to your Leader." on a tape loop. | 09:45.17 |
| chrisl | Robin_Watts: Hmm, that's not the latest commit in my local repo, how can that happen.... :-( | 09:52.41 |
| | Okay, I think that's gs906 where it ought to be | 10:04.35 |
| Robin_Watts | chrisl: I pushed some makefile/windows specific changes through on Friday to make metro builds possible | 10:09.26 |
| chrisl | Robin_Watts: I saw that, yes | 10:09.44 |
| Robin_Watts | I don't imagine you'll want to take them, but one of the things I had to do was to disable cups in the metro build. | 10:09.50 |
| | (As a default device, I mean) | 10:10.05 |
| chrisl | Fair enough. I'll remove it from the normal default build on Windows soon | 10:10.42 |
| Robin_Watts | ok. | 10:10.49 |
| chrisl | I wonder if I should make it activatable on the nmake command line..... | 10:12.42 |
| sebras | why can /Differences in a PDF font dict only describe the differences for the first 256 characters? I can't find a reference for this limitation. | 10:14.18 |
| kens | Because an Encoding can only have 256 entries | 10:14.47 |
| sebras | kens: oh, so MacRoman and WinAnsi and the like are all limited to 256 characters? | 10:15.38 |
| kens | sebras, yes, you cna only have 256 glyphs in a specific font instance, even if the font has more glyphs | 10:16.03 |
| | NB Type 1 fotns! | 10:16.11 |
| tor8 | kens, sebras: correct, except for type 0 fonts with multibyte encodings. but they are not "simple" fonts and use a different loading function in mupdf | 10:16.45 |
| kens | tor8 type 0 fotns (OCF) are not type 1 :-) | 10:17.16 |
| chrisl | The use of the Encoding keyword for Type 0 fonts is stupid and confusing :-( | 10:17.29 |
| tor8 | kens: well, nor are "simple" truetype fonts ;) | 10:17.33 |
| sebras | kens: what does "font instance" mean in this context? I'm confused. | 10:18.45 |
| kens | sebras, you can create a PostScript font by combining the font program with an Encoding | 10:19.08 |
| | You can do the same thing with the same font and a different Encoding | 10:19.23 |
| tor8 | hmm, I think I need a bigger desk. it's hard to fit three 24" monitors, two keyboards and a 15" laptop... even with one monitor turned into portrait mode | 10:19.31 |
| kens | Each of those is a 'font' and they use the same font program, but they can have different glyphs available | 10:19.51 |
| sebras | kens: but isn't there an inherent reference in the font program to a specific encoding? I mean each glyph renders a particular character in some script, right? | 10:20.50 |
| | kens: maybe that is the BaseEncoding then... | 10:21.05 |
| kens | sebras, no. | 10:21.07 |
| tor8 | sebras: this is the reason for the /Font and /FontDescriptor split I believe | 10:21.10 |
| sebras | tor8: ok.. still confused. :) | 10:21.27 |
| kens | Fonts have a built-in encoding (usually StandardEncoding) but it can be overrriden by a different one | 10:21.35 |
| | Because fonts are stored as dictionaries | 10:21.46 |
| | So the array associated with teh /Encoding key can be changed | 10:21.56 |
| tor8 | sebras: no, not really. for type1 fonts there is a "built in" encoding vector (which can be anything). truetype fonts have a set of 'cmap' tables with different (known) encodings | 10:22.02 |
| kens | If you do that, you usually want to give teh font a new name so that you can differentiate between them | 10:22.23 |
| tor8 | and when embedded in pdf files, it all gets hairy how to create the 'standard' encoding that the /Differences overrides. especially if the font is not embedded. | 10:22.42 |
| sebras | I'm looking at the type3 font code to try to understand it a bit better. | 10:24.35 |
| kens | type 3 fonts are more or less like type 1 fonts | 10:25.23 |
| | THey are described by a dictionary with various entries | 10:25.32 |
| | One of those is the encoding | 10:25.38 |
| sebras | there mupdf loads BaseEncoding and then parses Differences to override whatever the base encoding states. | 10:25.39 |
| kens | Yes. | 10:25.52 |
| | THe Encoding maps character codes to glyph names | 10:26.17 |
| | WHen you encounter a character code, you look it up in the encoding, that gives you a glyph name | 10:26.38 |
| | Then you get the CharStrigns dictioanry | 10:26.47 |
| | And look up hte name of the glyph in there | 10:26.55 |
| | (if you don't find one, then use /.notdef instead) | 10:27.05 |
| Robin_Watts | tor8: Have you looked at sebras changes yet? | 10:27.06 |
| | I was about to, but won't bother if you have/would rather do so yourself. | 10:27.26 |
| sebras | kens: ok, that makes sense. | 10:27.31 |
| tor8 | Robin_Watts: no, I just finish the "git remote update" command | 10:28.01 |
| kens | When you find the entry in Charstrings, its value is the actual program for the glyph, so you execute it. | 10:28.02 |
| sebras | kens: so then BaseEncoding (and Differences) are actually more related to the character codes in the string to be rendered than it they are with the fonts glyphs | 10:29.22 |
| tor8 | Robin_Watts: sebras: ar cr fix lgtm | 10:29.23 |
| sebras | ? | 10:29.25 |
| Robin_Watts | tor8: ok | 10:29.40 |
| sebras | tor8: I had a hard time parsing that. :) | 10:29.48 |
| kens | sebras, yes they are the method for mapping from character codes to glyphs, for rendering | 10:29.51 |
| | Its perfectly possible to change the Encoding and have the same string render totally different glyphs | 10:30.42 |
| sebras | kens: ok, getting less confused. but then how come that the character codes in the string are limited to 256? I mean there are other encodings such as unicode that have way more character codes defined... | 10:31.01 |
| | kens: yes, I can see that now. | 10:31.20 |
| kens | sebras when Adobe defined the original type 1 font format, they thought 256 were enough for anyone.... | 10:31.45 |
| sebras | kens: ok. but that's only for type 1 fonts. what about other types of fonts. type3? truetype? | 10:32.27 |
| kens | You can't use Unicode (direclty) with type 1 fonts. | 10:32.30 |
| sebras | do they work differently? | 10:32.34 |
| kens | sebras, yes, here's some more | 10:32.43 |
| | TYpe 3 fonts are the old way of working, they predate Adobe's pupblication of the type 1 sepc | 10:33.03 |
| | But theey work in exactly the same way, the difference is in the glyph data only. | 10:33.22 |
| | You can't use TrueType fonts directly in PostScript | 10:33.31 |
| | You have to convert them to type 42 | 10:33.38 |
| sebras | kens: what about in PDF? | 10:33.44 |
| kens | sebras, that's different again, let me finish these first | 10:33.57 |
| sebras | waits patiently. :) | 10:34.10 |
| kens | Type 2 fonts (also known as CFF0 work in the same way as type 1 but have a more compact representation of the glyph data | 10:34.29 |
| | Type 0 fonts are an ugly hack introduced by Adobe to get round the problem of only 256 glyphs per font | 10:35.03 |
| | A type 0 font has an array of descendant fonts, each of which can have 256 glyphs | 10:35.18 |
| | They take 2 byte codes, and the first byte tells you which descendant font to use. | 10:35.36 |
| | THe second byte is used to look up the Encoding of the descendant | 10:35.48 |
| sebras | right. | 10:35.56 |
| kens | These were replaced by CIDFonts | 10:36.01 |
| | A CIDFont is composed with a CMap to create a type 0 font | 10:36.16 |
| | (You needn'e worry about the type 0 in this case though) | 10:36.27 |
| | The CMap tells the font interpreter how many bytes to read for a glyph. | 10:36.42 |
| | Sorry character code | 10:36.48 |
| | And it can be variable. | 10:36.56 |
| | So you might say bytes 0->127 = 1 byte this is the character code | 10:37.11 |
| sebras | mm, and it consists of various ranges and tables as far as I have seen. | 10:37.23 |
| kens | bytes 128->256 = 2 bytes | 10:37.25 |
| | sebras, yes those are the mappings I'm describing | 10:37.39 |
| sebras | I know that there's some offset involved in all of this... | 10:38.07 |
| kens | Basically the CMap telss you how many bytes to read, and contains a mapping of the character codes to 'CID's | 10:38.08 |
| | THe CharStrings dictionary for a CIDFont contains CIDs, not names (CIDs are numeric) so you can acccess *lots* of glyphs in one program | 10:38.46 |
| | internally the font interpreter creates a type 0 to handle this, but you needn't worry about that. | 10:39.16 |
| sebras | alright. | 10:39.27 |
| kens | Now in PDF you *can* use TrueType fonts directly | 10:39.28 |
| | Thsoe are also slightly ugly because of the Symboli/Non-Symbolic stuff | 10:40.01 |
| | If a font is symbolic it should not have an Encoding IIRC | 10:40.14 |
| | And the character codes map to GIDs | 10:40.26 |
| | If its non-symbolic then you do have an Encoding and the character codes are mapped through the Encoding, which returns a GID | 10:40.47 |
| sebras | what are GIDs? similar to CIDs? | 10:40.59 |
| kens | I'm slightly hazy about that one, so if I'm wrong I hope chrisl or tor8 will correct me | 10:41.06 |
| Robin_Watts | tor8, sebras: (When kens has finished) I think there is a problem with sebras type3 font patch. | 10:41.15 |
| kens | sebras GIDs are the internal lookups for TT fonts (Glyph IDs) | 10:41.29 |
| sebras | kens: right, but then they do the same job as the CIDs do in CIDFonts. correct? | 10:42.00 |
| kens | The GLYF table in the font contains a list of fonts referenced by GID (there is another table which gives you the offset form the start of the font to the start of each GID) | 10:42.08 |
| | sebras, broadly speaking yes, but the mwechanisms are different | 10:42.23 |
| tor8 | "symbolic" fonts are fonts that don't map to unicode or another known encoding, so the glyph names aren't useful. indexed directly by glyph index and must be embedded. in theory at least... | 10:42.52 |
| kens | sebras is that enough detail ? | 10:42.54 |
| sebras | kens: so Encoding in the non-symbolic Truetype case, is how is that related to unicode? | 10:43.08 |
| kens | sebras it isn't | 10:43.19 |
| tor8 | sebras, kens: for CJK fonts, the CIDs serve the same function as the glyph names in regular type 1 fonts | 10:43.42 |
| kens | I don't believe you can use Unicode directly with TT fonts in PDF any more than you cna type 1 fonts | 10:43.42 |
| sebras | kens: so what if my string is a unicode string? | 10:43.43 |
| kens | sebras, if its 1 byte then you cna ,ap the font in a way that allowqs you to use it | 10:44.06 |
| | If its > 1 byte per character, then you have to use a CIDFont | 10:44.18 |
| | Now CIDFonts come in different flavours | 10:44.26 |
| | Depending on the type of font data | 10:44.33 |
| | A CIDFont can have outline data in any of the preceding formats (type 1, 2, 3, 42) | 10:44.50 |
| | Or you can translate your Unicode string into whatever 1-byte character code mapping suits you, and build an Encoding array to suit. THe content of the Encoding will depend on the ofrmat of the font | 10:45.56 |
| kens | feels sebras is probably more confused than ever | 10:46.18 |
| tor8 | sebras: the common way to use unicode and truetype fonts in PDF is to create a CID font, with a two-byte Identity-H CMap and use the CIDToGIDMap | 10:46.40 |
| sebras | struggles to parse that last message. | 10:46.44 |
| kens | ssebras, my mesage ? | 10:47.18 |
| sebras | tor8: baby steps, tor8, baby steps.... | 10:47.24 |
| kens | sebras, actually that is the easy way.... | 10:47.38 |
| | What tor8 suggests | 10:47.46 |
| tor8 | sebras: pdf/pdf_font.c load_cid_font is where you want to start looking if you want to understand multibyte or unicode fonts in mupdf | 10:47.55 |
| sebras | kens: yes. ok. so you're saying that I could translate the string and create a custom encoding to match the glyphs of my CIDFont? | 10:48.11 |
| tor8 | sebras: the most common way is to embed the font and in the content stream use the glyph indexes directly | 10:49.04 |
| kens | sebras I mean you could change your Unicode character codes into some other set of character codes (1 byte per character) and then create a custom Encoding (or CMAp) to apply to your font, so that the one byte character codes would get the right glyphs | 10:49.14 |
| sebras | tor8: yeah, I know. I just need to rearrange my neurons a bit so I can parse the source first. you know there isn't terribly many comments in the code. | 10:49.15 |
| tor8 | sebras: and create a ToUnicode cmap to create the reverse lookup from glyph index to unicode character | 10:49.24 |
| sebras | tor8: aha! and that reverse lookup is used when copying text then..? | 10:50.01 |
| tor8 | sebras: yes, that's the only place it's used | 10:50.13 |
| kens | sebras ToUnicode CMAps are used to search and copy/paste | 10:50.30 |
| tor8 | sebras: for drawing the text, unicode is very rarely (if ever) used | 10:50.39 |
| kens | The character codes are used to access teh CMap and return a Unicode equivalent | 10:50.47 |
| tor8 | sebras: for CID fonts in PDF there are (thankfully) only a few ways to do it | 10:51.45 |
| | 1) use the Identity-H or Identity-V encoding -- the content stream directly accesses glyph indexes | 10:52.09 |
| sebras | kens: I think I might owe you a new keyboard now. one that misspells less. ;) | 10:52.20 |
| tor8 | 2) use a standard CMap (for CJK fonts) which maps to a known encoding | 10:52.28 |
| sebras | tor8: how do Identity-H and Identity-V differ? or more importantly -- why? | 10:53.10 |
| tor8 | truetype fonts have one extra trick up the sleeve, the CIDToGIDMap which just adds an extra lookup table indirection for accessing the glyph IDs | 10:53.29 |
| | sebras: only in the writing direction | 10:53.36 |
| | i.e. which set of metrics to pick | 10:53.44 |
| | and how to adjust the currentposition after each glyph | 10:53.56 |
| sebras | tor8: aha. Is that part of the cmap? I would have thought that this was part of each glyph pointed to by an entry in the cmap..? | 10:54.46 |
| tor8 | sebras: in truetype there are separate tables for metrics. a truetype font has the 'glyf' table for outline data, 'cmap' table for encodings, and 'hmtx' and 'vmtx' for horizontal and vertical metrics | 10:55.35 |
| | so the metrics are kept separate from the glyph data (but indexed by the same glyph index) | 10:56.25 |
| sebras | alright, at least now I understand why Encoding is inherently imited to 256 codes. thanks kens and tor8! | 10:58.42 |
| | also I save this discussion so I can reference it later once I become confused again. | 10:59.06 |
| | Robin_Watts: what type3 patch? | 10:59.14 |
| | Robin_Watts: and how is it wrong? | 10:59.21 |
| | tor8: hm.. one more question -- if a font has a BaseEncoding and a Differences array and one of the character codes mentioned in Differences is outside of the valid range (0-255), then what should we do? | 11:01.46 |
| | to me it seems best to just ignore the entire difference up until the next character code altogheter. what's your take on it? | 11:02.23 |
| Robin_Watts | sebras: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=f317c5317f14f2911789d309d7295146297c1838 | 11:03.48 |
| | When it goes wrong now, you drop the fontdesc, then throw, which gets caught, and drops the fontdesc. | 11:04.20 |
| sebras | Robin_Watts: d'oh. I fix. | 11:04.43 |
| | Robin_Watts tor8: I'm pushing this patch fixed (with a reworded commit message) now. | 11:08.44 |
| Robin_Watts | http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=4e7dd1a7e64cf4dd8f9dd28a236d285df572a1c0 | 11:08.49 |
| | I'm not sure we should ever call jpeg_destroy_decompress on something that hasn't been to jpeg_create_decompres | 11:09.47 |
| | I think I'd be happier if we moved the state->init = 1 to be immediately after the call to jpeg_create_decompress | 11:10.14 |
| | Would that satisfy you sebras? | 11:10.25 |
| sebras | Robin_Watts: yes it would. I haven't checked if we use state->init elsewhere yet though... | 11:10.55 |
| Robin_Watts | Looks safe to me. | 11:12.06 |
| sebras | Robin_Watts: same here. | 11:12.14 |
| Robin_Watts | Why -m for mudraw? | 11:14.22 |
| | -n even | 11:14.25 |
| | Is -n a unix standard? | 11:14.44 |
| sebras | Robin_Watts: because I was running it over 13000 PDF | 11:14.47 |
| Robin_Watts | No, I mean, why -n rather than -i ? | 11:15.18 |
| sebras | s the other night. quite a few are so broken that MuPDF fails to render them and errors out instead. | 11:15.21 |
| | Robin_Watts: -i is taken, right? | 11:15.27 |
| Robin_Watts | -I is taken. | 11:15.36 |
| | and -l (lower case L) | 11:15.58 |
| sebras | Robin_Watts: and I wanted to make sure that mudraw tried to draw all PDFs. | 11:16.00 |
| Robin_Watts | I understand the purpose. | 11:16.09 |
| | It was purely the choice of letter I was questioning. | 11:16.17 |
| sebras | Robin_Watts: ah. :) | 11:16.24 |
| | Robin_Watts: I'm happy to change the option if you can come up with something more appealing. :) | 11:16.48 |
| Robin_Watts | make uses -i for ignore errors. | 11:17.01 |
| | (or --ignore-errors) | 11:17.07 |
| | so, I'd personally vote for -i | 11:17.29 |
| sebras | oh... now I see what you mean. -i isn't taken at all! | 11:18.09 |
| Robin_Watts | Ok, I've now looked at all your patches, and (with the exception of the stuff I've mentioned here) they look great. Thanks! | 11:19.04 |
| sebras | Robin_Watts: soon there will be another couple of patches filtered through me from Zeniko. | 11:19.46 |
| Robin_Watts | sebras: That is also much appreciated! (And thanks for crediting Zeniko in the commit messages. He gets shirty otherwise :) ) | 11:20.35 |
| | tor8: Would it help for me to pull together a new thirdparty.zip ? | 11:20.53 |
| sebras | Robin_Watts: freetype 2.4.10! :) | 11:21.08 |
| Robin_Watts | sebras pointed out a new freetype yesterday, and there are openjpeg fixes from shelly etc. | 11:21.22 |
| sebras | Robin_Watts: hm.. setting state->init earlier won't work. | 11:25.10 |
| Robin_Watts | how come? | 11:25.27 |
| tor8 | sebras, Robin_Watts: the "add option to mudraw to process further files upon error" -- maybe that should be the default behavior with no option instead? | 11:25.36 |
| sebras | Robin_Watts: the reason is that you're not allowed to call jpeg_finish_decompress() when cinfo->global_state == DSTATE_START which it is set to in jpeg_create_decompress(). | 11:26.09 |
| tor8 | I'm not really happy about the "Throw exception on too deeply nested" ... maybe it's just the function naming though | 11:26.20 |
| sebras | tor8: I'm not sure about that default behaviour. normally you would want to detect the bogus pdf easily. but when your running coverage testing you don't want that. | 11:27.01 |
| Robin_Watts | I changed mudraw recently to return a non-zero error code on rendering errors. | 11:27.04 |
| | I wonder if that shouldn't be tied into the ignore-errors thing... | 11:27.18 |
| sebras | Robin_Watts: that would work of course. | 11:27.33 |
| tor8 | sebras: with robin's fix that he just mentioned, I don't see much need | 11:27.35 |
| sebras | tor8: nope, I agree. | 11:27.45 |
| tor8 | we can check the error code (and I guess we should return non-zero if any errors were detected) | 11:27.58 |
| | if you only care about one file, only run one file | 11:28.05 |
| sebras | tor8: then I'll whip up a patch to change ignore errors to the default behaviour instead. | 11:28.05 |
| Robin_Watts | What have we just agreed on? :) | 11:28.07 |
| | No, I don't think ignoring errors should be the default. | 11:28.24 |
| | If we hit an error, it should stop processing and return with a non-zero error code. | 11:28.52 |
| sebras | tor8: sure, I was thinking more along the lines -- if I run over many files I want to be able to detect errors easily (without having to look through 1000s of lines of output). | 11:29.00 |
| tor8 | Robin_Watts: the question is what happens if you ask mudraw to process more than one file at a time | 11:29.23 |
| Robin_Watts | The question (in my eyes at least) is whether, if the -i flag is specified, we should swallow every rendering error, keep going through the list of files, and return 0 at the end. | 11:29.46 |
| | tor8: Right. And I think that if we hit an error, we should stop immediately without looking at more files. | 11:30.13 |
| tor8 | Robin_Watts: I could live with that. | 11:30.19 |
| | just wanted to throw the question out there | 11:30.28 |
| Robin_Watts | I mean, we have no way of signalling where the error occurred in a list of files. | 11:30.37 |
| | So either we ignore all of the errors (in which case we keep going), or we stop on the first one. | 11:31.01 |
| tor8 | Robin_Watts: which is why I thought if you care about which file, run them one by one in a loop instead of with one call to mudraw | 11:31.02 |
| Robin_Watts | tor8: indeed. | 11:31.11 |
| | If you want more flexibility you can always call mupdf programmatically. | 11:31.23 |
| sebras | so...? what's the consensus? | 11:32.10 |
| Robin_Watts | I think the consensus is: | 11:32.23 |
| | 1) Default stays as it is. | 11:32.28 |
| | 2) If the -i flag is set, then swallow all errors, continue running through the list, still return 0 at the end. | 11:32.49 |
| sebras | Robin_Watts: why return 0 in case of errors with -i ? | 11:33.18 |
| Robin_Watts | (Default is therefore: on error, stop immediately, returning a non-zero code.) | 11:33.37 |
| sebras | Robin_Watts: you could still use the exit code to signal that there is something worth looking at somewhere in the output. | 11:33.39 |
| Robin_Watts | Because you said to ignore errors. | 11:33.50 |
| | And if you're using it in a makefile or script, that's what ignoring errors means. | 11:34.04 |
| | tor8: fz_overly_profound ? | 11:34.26 |
| | fz_crush_depth ? | 11:34.39 |
| sebras | Robin_Watts: alright, then. | 11:34.44 |
| tor8 | sebras: I agree with robin's summary of the consensus. | 11:35.07 |
| | sebras: also, you've got a handful of typos (s/and/an/) in the commit messages and a few "what's that supposed to mean" grammar issues. was it late night when you typed them? ;) | 11:36.02 |
| | sebras: also, you asked me about error messages having "too few/many inputs" ... why not say "wrong number of inputs" instead? | 11:36.59 |
| sebras | tor8: yes, it was quite late. I'll read through them and poke you when I'm done. | 11:37.59 |
| tor8 | sebras: enjoying your vacation? :) | 11:38.28 |
| Robin_Watts | tor8: see my earlier question about thirdparty.zip? | 11:38.33 |
| sebras | tor8: you already merged the other "too few/many inputs", so I wanted to stay consistent. | 11:38.37 |
| tor8 | Robin_Watts: ah, right. yes, I think we should update it at least for freetype | 11:38.56 |
| | the openjpeg fixes you mentioned, are they upstream yet? | 11:39.05 |
| | sebras: it's okay, we can reword the error messages in a separate commit later | 11:39.25 |
| Robin_Watts | They have been accepted upstream. Not sure that they have been release upstream though. | 11:39.27 |
| | There may also be jbig2dec stuff to put in. | 11:40.04 |
| tor8 | Robin_Watts: I would prefer if we could stick to released version for the thirdparty zip | 11:40.07 |
| | except the jbig2dec which we ought to roll up a release of soon. chrisl? :) | 11:40.26 |
| chrisl | tor8: yes, "we" ought to..... | 11:41.08 |
| Robin_Watts | upstream openjpeg hasn't been updated since feb. | 11:41.13 |
| | I'd really like to get the segv fixes in though, as it was with mupdf that I detected them (with a potentially LARGE customers example files) | 11:42.08 |
| tor8 | chrisl: take a day next week maybe, and sort out the jbig2dec vs ghostpdl git diffs? | 11:42.33 |
| | Robin_Watts: right, let's make an exception for this thirdparty.zip then (but do note which svn revision we use in the tarball) | 11:43.15 |
| chrisl | tor8: I was hoping the jbig2dec vs ghostpdl trees were now in-sync..... | 11:43.32 |
| tor8 | call the directory openjpeg-svnXYZ or so? | 11:43.35 |
| Robin_Watts | I'm just svn checkouting now. | 11:43.48 |
| | The SVN checkout has OPJ_MINOR set to 99 rather than 5 | 11:48.05 |
| | Oh, and I have a fix to the jpeglib, which again has been accepted upstream, but not released yet. | 11:54.06 |
| | how about we ship openjpeg-1.5+ with a note in saying that we've pulled in r1729 and r1730 too ? | 11:56.25 |
| | r1728 and r1730 even. | 11:56.53 |
| | Hmm. My changes are in the development version of libjpeg on http://www.infai.org/jpeg/ | 11:59.09 |
| | (actually technically they are Rillians changes originally I think) | 11:59.29 |
| sebras | tor8 Robin_Watts: I think I fixed all your issues with my patches now (and added one or two more of Zenikos). | 12:08.34 |
| Robin_Watts | There are lots of jbig2dec changes in GhostPDL that aren't in the standalone jbig2dec git repo. | 12:16.13 |
| | chrisl, tor8: Any objections if I move them across ? | 12:16.23 |
| | (git format-patch then git am ?) | 12:16.46 |
| chrisl | Robin_Watts: I'm trying to do it now, without losing the history - struggling..... | 12:16.56 |
| tor8 | chrisl, Robin_Watts: time to try out the "git subtree" command? | 12:17.16 |
| Robin_Watts | chrisl: Will git format-patch then git am not keep the history in the way you need? | 12:17.25 |
| tor8 | in the past I've done git filter-branch --subdirectory and then cherry picked across | 12:17.43 |
| | Robin_Watts pointed me to an option of format-patch to make a patch for only a subdirectory | 12:18.04 |
| chrisl | Robin_Watts: I'm getting most of the patches failing to apply :-( | 12:18.06 |
| Robin_Watts | chrisl: Ah. | 12:18.17 |
| | tor8: did I? :) | 12:18.38 |
| tor8 | Robin_Watts: well, at least you prodded me about format-patch enough that I found the option myself. which counts too, right?; ) | 12:19.19 |
| Robin_Watts | chrisl: how come they are failing to apply? Is it stuff outside the subdir causing problems ? | 12:25.45 |
| | If so, tor8's technique may solve that. | 12:26.01 |
| chrisl | Robin_Watts: I'm getting useful messages like: "error: patch failed: jbig2_image.c:229" | 12:26.21 |
| Robin_Watts | ah. | 12:26.32 |
| chrisl | I was going to try having more lines of context in the diff.... | 12:26.57 |
| Robin_Watts | chrisl: I'm going to get lunch. If you want me to have a go afterwards, please just say. | 12:28.17 |
| mariomop_ | hi people | 12:43.21 |
| | I have a question about gs in windows (XP by the way) | 12:44.06 |
| sebras | mariomop_: go ahead. I don't know gs well myself, but I know there are others here that are. | 12:45.03 |
| | s/are\./do/ | 12:45.16 |
| mariomop_ | thanks sebras, the problem is that when we print documents with many pages (more than 50), the first pages are printed as we expect, but at certain point the font size get smaller | 12:45.52 |
| kens | mariomop_ that is not a bug I have heard of. | 12:46.52 |
| | What version of GS are you using ? | 12:47.00 |
| | and how are you using it to print ? | 12:47.14 |
| mariomop_ | I dont know if i'm clear, but imagine that the first 30 pages are printed ok, but then the letters get smaller, a little smaller | 12:47.21 |
| | the last one, for windows | 12:47.44 |
| kens | Version number please | 12:48.04 |
| mariomop_ | 9.x dont remember now, but I can tell if you want | 12:48.08 |
| kens | It would be helpful | 12:48.17 |
| | It could be any of 5 different vesions in teh 9.x seriews | 12:48.30 |
| | Also how are you using GS to print ? | 12:48.48 |
| mariomop_ | 9.02 | 12:49.23 |
| kens | Te 'last' version was 9.05, 9.06 will be released i a few days | 12:49.52 |
| | My first suggestion would be to upgrade | 12:50.05 |
| mariomop_ | ok, gs is used to generate pdf | 12:50.41 |
| | by an application | 12:50.55 |
| kens | Have you checked the paegs in the PDF ? | 12:51.28 |
| mariomop_ | ok, I'll update | 12:51.39 |
| | how so? | 12:51.52 |
| | I have seen them in pc, and printed | 12:52.13 |
| | this is a problem in windows, but not in linux | 12:52.38 |
| kens | Well if you are printing the PDF file then GS is not 'printing' the file | 12:52.44 |
| | So the question is whether the PDF is OK, if it is, tehn its not a GS problem | 12:53.17 |
| mariomop_ | no, the pdf is wrong | 12:53.32 |
| kens | Well then I strongly suggest you upgarde | 12:53.48 |
| | If the problem persists, you should open a bug report | 12:54.02 |
| | at http://bugs.ghostscript.com | 12:54.23 |
| henrys | wow what an incredible olympics for the UK, you should host more often. | 12:54.28 |
| chrisl | henrys: we'd go bankrupt! | 12:54.43 |
| mariomop_ | ok, yes, its quite strange a bug for us too | 12:54.51 |
| | or at least strange behaviour | 12:55.09 |
| | thanks kens | 12:55.30 |
| Robin_Watts | back. | 13:08.24 |
| | chrisl: You having any luck ? | 13:08.33 |
| chrisl | Robin_Watts: everything's applied except for the memento one, I'm just looking at that now..... | 13:09.00 |
| henrys | a 2 1/2 year old regression, another glorious Monday! | 13:12.30 |
| | chrisl:sell the gold medals on ebay they go for a bundle. | 13:13.25 |
| chrisl | henrys: I suspect the competitors might want to hang onto them..... | 13:14.13 |
| Robin_Watts | henrys: We're doing it all wrong. | 13:14.34 |
| | We don't even tax the competitors earnings :( | 13:14.43 |
| henrys | just have all the athletes pony up the medals, look at these prices:http://www.mentalfloss.com/blogs/archives/136386 - the gold medal isn't even made of gold, it's most silver. | 13:23.33 |
| Robin_Watts | henrys: The athletes should pay tax on any earnings they make (including the medals etc and bribes^H^H^H^H^Hincentive payments from their own countries) within the UK. | 13:27.25 |
| | But we passed a special olympics bill that exempts them all. | 13:27.40 |
| | (and all the sponsors etc) | 13:27.52 |
| kens | missed that little one | 13:28.00 |
| Robin_Watts | But the US with it's "worldwide" taxation system plans to tax the athletes on such payments. | 13:28.33 |
| | But there are plans to avoid it: http://www.washingtontimes.com/news/2012/aug/1/rubio-bill-eliminates-federal-tax-olympic-medals/ | 13:29.32 |
| | But it's a bit of a swizz really. | 13:30.14 |
| chrisl | Robin_Watts: can you double check this for me, please: http://git.ghostscript.com/?p=user/chrisl/jbig2dec.git;a=commitdiff;h=74129652 | 13:30.24 |
| Robin_Watts | Yes, they get a tax bill, but it's more than paid for by the 'honorarium' they are paid. So no one is actually out of pocket by winning a medal. | 13:30.58 |
| | chrisl: That looks good to me. | 13:31.57 |
| | And I see why it would have been tricky to reapply - simultaneous changes within the subdir and in the gs source. | 13:32.18 |
| henrys | Robin_Watts:I imagine that money would pale in comparison to tax revenue that comes from endorsements which is presumably just an income tax. | 13:33.50 |
| sebras | tor8 Robin_Watts: new patch from Zeniko. | 13:34.57 |
| chrisl | Robin_Watts: that wasn't a big problem, a little patch pruning sorted it out. The problem is, in jbig2dec, the Makefile.in is a derived file, created from Makefile.am..... | 13:35.45 |
| Robin_Watts | henrys: Yes, I have no objection to us not taxing athletes on medals etc. | 13:41.33 |
| chrisl | Robin_Watts: that taxation thing is weird, surely they can write off most/all of the prize money as expenses? | 13:42.21 |
| Robin_Watts | It's the fact that sponsors are similarly exempt from some tax bills too. It was pointed out in the press recently over here, with a noticable amount of public outcry. | 13:42.48 |
| | chrisl: I'd imagine that athletes have their expenses paid for them by their countries olympic committees. | 13:43.18 |
| chrisl | Still, with a little inspired accounting...... | 13:44.11 |
| sebras | Robin_Watts: in make_page_offset_hints() there are two variables, max and min, which are asserted on. zeniko points out that the assert is not valid for i == xref->len - 1 | 14:08.37 |
| Robin_Watts | looking | 14:13.03 |
| | sebras: When we linearise (the only case where we make the hints tables), we order the objects in the file: opts->start ... opts->xref-1, 1 .. opts->start-1 | 14:15.54 |
| | So, I believe max > min, unless there is something I'm failing to see ? | 14:16.52 |
| | Does Zeniko have a bug related to this? | 14:17.02 |
| sebras | no, this is the only thing in the patch: | 14:17.15 |
| | + /* SumatraPDF: TODO: this assertion doesn't hold for i == xref->len-1 */ | 14:17.16 |
| | assert(max > min); | 14:17.19 |
| | but I could ask him for file demoing the problem if you want. | 14:17.39 |
| Robin_Watts | Well, in the absence of an example, I'll be ignoring it :) | 14:17.50 |
| | If you want to follow up with him, please do! | 14:18.03 |
| sebras | Robin_Watts: sure, I will. | 14:18.20 |
| Robin_Watts | This stuff is complex enough that there could easily be a dumb mistake somewhere. | 14:18.35 |
| | but I suspect that if he's seeing the assert fail, it's symptomatic of a problem elsewhere. | 14:18.55 |
| | and patching it here is wrong. | 14:19.01 |
| sebras | yeah, sumatrapdf is known to detect problems quite often, but may not patch it in the right location all the time. I'll mail Zeniko and ask. | 14:19.46 |
| Robin_Watts | chrisl: So, are you going to push your changes back to jbig2dec? Or are you waiting for some tests or something? | 14:21.34 |
| chrisl | Robin_Watts: I've Shelly to (quickly) review the commits, then I'll push them back to jbig2dec | 14:22.14 |
| | asked ^^ | 14:22.23 |
| Robin_Watts | tor8: I have a new thirdparty all prepared except for jbig2dec then. | 14:22.53 |
| chrisl | Shelly's just replied saying he's happy with the "merge", so I guess we're good to go..... | 14:23.40 |
| sebras | chrisl: btw, I believe that there is a free of GR_stats waiting to be added at the end of jbig2_symbol_dictionary(). | 14:23.54 |
| chrisl | sebras: do you mean I've missed something, or is that a new issue (to us)? | 14:24.33 |
| sebras | chrisl: new issue. | 14:24.46 |
| | chrisl: I ought to send a bug. | 14:24.55 |
| chrisl | sebras: please do..... | 14:25.07 |
| sebras | chrisl: I'll do it immediately. | 14:25.16 |
| Robin_Watts | sebras, thanks. | 14:25.23 |
| sebras | I noticed the leak last night, but was too tired too report it. | 14:26.29 |
| chrisl | sebras: can you check here: http://git.ghostscript.com/?p=user/chrisl/jbig2dec.git;a=blob;f=jbig2_symbol_dict.c;h=49ba2285 | 14:28.00 |
| | at least one route through the code frees GR_stats | 14:28.24 |
| sebras | chrisl: oh. | 14:28.38 |
| | I'll go back and check if this would solve the leak I saw last night. | 14:28.59 |
| chrisl | Robin_Watts: I've pushed the changed to jbig2dec.git | 14:32.30 |
| Robin_Watts | Thanks. | 14:33.36 |
| chrisl | I just hope it's right..... | 14:33.55 |
| alexcher | I have OpenJpeg 1.5 working locally. Should I just commit it directly or split into several commits: original version that doesn't compile, portability patches, our patcehs, security patches. | 14:40.38 |
| Robin_Watts | alexcher: We have 1.5 working within mupdf. | 14:41.31 |
| | Is this a newer version of 1.5 ? | 14:41.41 |
| | or is the 'non-compiling' down to the way gs interacts with it? | 14:42.20 |
| alexcher | No, it's the latest release. Ghostscript is still using 1.4. | 14:43.33 |
| Robin_Watts | alexcher: So you've taken their 1.5 release and added fixes to that? I wonder whether we should be using that in mupdf? | 14:44.30 |
| alexcher | The interface has changed a little between 1.4 and 1.5 releases. | 14:44.35 |
| chrisl | alexcher: we don't want commits that don't build, because it makes bisecting a pain. | 14:44.46 |
| Robin_Watts | Currently in mupdf we are using (I believe) a vanilla 1.5 release with revisions 1728 and 1730 pulled in from SVN (those were shellys fixes he did for us, and fed back to the maintainers) | 14:45.11 |
| | chrisl: I suspect the way to handle that is to create a branch, and put all the (potentially broken) history on that branch. | 14:46.21 |
| | THen merge than branch down to the trunk. | 14:46.27 |
| chrisl | Yes, that would be good. | 14:46.38 |
| Robin_Watts | I believe the cluster will then only test the merge itself. | 14:46.40 |
| | and it keeps the history visible. | 14:46.49 |
| chrisl | I'm concerned that pulling in 1.5 isn't appropriate for 9.06 at this late stage, but then we won't have the security fixes :-( | 14:47.17 |
| Robin_Watts | I'd say it was too late for 9.06 personally. | 14:47.42 |
| chrisl | alexcher: how much effort would it be to apply just the security fixes to the 1.4 code currently in gs? | 14:48.31 |
| alexcher | chrisl: one patch is quite simple. I didn't look at others because they were already included in v. 1.5. | 14:49.45 |
| Robin_Watts | tor8: http://ghostscript.com/~robin/mupdf-thirdparty-2012-08-06.zip | 14:50.50 |
| | tor8: Want to give that a quick once over? | 14:50.58 |
| chrisl | Hmm, I thought an open source jpx encoder was legally problematic...... | 14:55.47 |
| henrys | if the security patches are important we can post a notice and patch on the web site. | 15:01.32 |
| Robin_Watts | tor8: Dunno if you saw what I said just before the net split. | 15:03.32 |
| | tor8: http://ghostscript.com/~robin/mupdf-thirdparty-2012-08-06.zip | 15:03.35 |
| | tor8: Want to give that a quick once over? | 15:03.37 |
| henrys | Robin_Watts, tor8:is a mupdf release coming? I'd like to write the newsletter stuff do you have release notes I can look at? | 15:04.02 |
| Robin_Watts | henrys: That's why I'm redoing the thirdparty.zip file. | 15:04.46 |
| | I've certainly not done any release notes, dunno about tor8 ? | 15:07.11 |
| chrisl | Robin_Watts: what do you think of this? http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=d52975ea | 15:07.48 |
| Robin_Watts | I like it. | 15:08.35 |
| chrisl | It saves remembering that libpaper has that issue.... | 15:09.09 |
| Robin_Watts | Hold on... | 15:09.16 |
| | Isn't the problem that libpaper returns something from malloc rather than Memento_malloc | 15:09.35 |
| | which we then free with Memento_free ? | 15:09.54 |
| sebras | chrisl: no, the free in the non-error patch in jbig2dec didn't do it. | 15:10.02 |
| Robin_Watts | I don't see how your change will fix that. | 15:10.04 |
| sebras | chrisl: I'll report a bug with a patch. | 15:10.17 |
| chrisl | Yes, so with MEMENTO defined, we call the function std_free(), without MEMENTO we just call free() | 15:10.31 |
| | std_free() is defined *before* memento gets the chance to redfine free() to Memento_free() | 15:11.07 |
| Robin_Watts | Ah! | 15:11.13 |
| chrisl | It's a pretty horrid trick I've used in the past...... | 15:11.37 |
| Robin_Watts | ok. A comment to the effect that "Define std_free before including memento.h" | 15:11.48 |
| | ... would be worth adding, I reckon. | 15:12.00 |
| chrisl | I thought was implicit in the comment, but I'll make it clearer.... | 15:12.36 |
| | Robin_Watts: clearer? http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=5ae5e2a7 | 15:15.59 |
| Robin_Watts | spot on. even my tiny mind can follow that :) | 15:16.26 |
| chrisl | Cool, I'll push that, then. Thanks! | 15:16.45 |
| sebras | argh! bugzilla doesn't complain about password length if I reset my password, enter at too long (>16 chars) password. however if I reset it to something short, then go into preferences and change the password there, then bugzilla complains about the password length. :-/ | 15:18.06 |
| | chrisl Robin_Watts: http://bugs.ghostscript.com/show_bug.cgi?id=693256 here you go. | 15:22.37 |
| chrisl | sebras: looks okay. Should we also free GB_Stats in the same place? | 15:25.38 |
| sebras | chrisl: yes. I forget to check that GB_stats used to be freed by jbig2_decode_symbol_dict() in mupdfs version of jbig2dec. | 15:30.01 |
| Robin_Watts | Hmm. Many diffs with the new thirdparty. | 15:31.54 |
| | What did I break? | 15:32.00 |
| chrisl | sebras: in which case, should we just move the two "free" calls out of the "else" clause? | 15:32.10 |
| | Robin_Watts: I'd expect diffs with the new Freetype...... | 15:32.46 |
| sebras | chrisl: naa, I think that's a bad idea. GB_stats and GR_stats are freed only in the error case because I don't know how to retain them properly. I don't know the jbig2dec code or the jbig2 spec well enough to fix this proper, so freeing them is just a workaround. | 15:33.08 |
| Robin_Watts | I spotted it too, but came down on the same side of the fence as sebras (hence didn't mention it) | 15:34.35 |
| chrisl | sebras: I assumed from the comment that retaining GR_stats and GB_stats was an optimisation - it just looks a little odd having the two routes through the code doing the same thing..... | 15:35.28 |
| sebras | chrisl: I agree with you in principle, but I wonder what "bitmap coding context retained" means in JBIG2 spec... | 15:36.39 |
| | until that is resolved I would keep the two paths separate since I think that the freeing of GB_stats/GR_stats may actually be wrong once the context retention is implemented. | 15:37.33 |
| | chrisl: I updated the patch. | 15:37.54 |
| chrisl | <shrug> it's not a big deal - it should pretty clear to anyone that implements retaining them, that they shouldn't be freed! | 15:38.03 |
| sebras | yeah, but this means the freeing if close to the comment about it not being implemented. :) | 15:38.37 |
| chrisl | sebras: I'm just going to test it under gs on the cluster - as a sanity check. | 15:43.52 |
| sebras | chrisl: of course. I hope there are no issues with it. | 15:44.27 |
| chrisl | sebras: It's clearly wrong (to not retain *and* not free the memory), so I really doubt the cluster will throw up any regressions | 16:04.25 |
| sebras | chrisl: me too. | 16:05.10 |
| | if this patch makes it to Robin_Watts' new thirdparty.zip I would be happy though. | 16:05.36 |
| chrisl | sebras: the guy whose been doing a lot of the fixes in jbig2dec said he couldn't find an example file that used that retained feature - it sounds like you have one, then? | 16:05.54 |
| sebras | yes, inside a pdf. I can dig it out. | 16:06.26 |
| chrisl | sebras: if you could share it (the PDF) that would be great - maybe open a bug about the missing feature? I can make the file private if need be..... | 16:07.23 |
| Robin_Watts | sebras: I will be sure to include it. | 16:08.04 |
| sebras | Robin_Watts: thanks! :) | 16:09.45 |
| Robin_Watts | I am confused. | 16:11.53 |
| | I have yet to see any diffs in the bmpcmp that can't be considered progressions. | 16:12.13 |
| | but I can't explain why lots of them are there at all... | 16:12.33 |
| chrisl | This is often considered a positive thing...... | 16:12.44 |
| kens | With what patch ? | 16:12.51 |
| Robin_Watts | Changing the thirdparty. | 16:13.00 |
| kens | oh, tha's a bit odd | 16:13.13 |
| Robin_Watts | I expect to see changes from freetype. | 16:13.21 |
| | and I could accept small changes from jpeg or openjpeg or jibg2dec. | 16:13.42 |
| | http://ghostscript.com/~regression/robin/compare.html | 16:14.49 |
| | But what's number 37 about, for instance? | 16:14.57 |
| | Did we ever render "SouthGate Bath" in red and cyan ? | 16:15.41 |
| chrisl | Could it be an image? | 16:17.07 |
| Robin_Watts | Previous experimentation with that file says no. | 16:17.46 |
| | (but I can't be sure). | 16:18.00 |
| | I think I may try repushing with only part of the thirdparty changed. | 16:18.14 |
| chrisl | That's an especially horrid file to find a problem in, too! | 16:22.12 |
| | sebras: cluster was fine - patch committed. Thanks! | 16:29.29 |
| sebras | chrisl: excellent! | 16:30.18 |
| chrisl | Robin_Watts: sebras's patch is in jbig2dec.git | 16:31.08 |
| Robin_Watts | Thanks. | 16:34.44 |
| sebras | yey.\ | 16:34.54 |
| | Robin_Watts: I got a file from zeniko that triggers the asset. | 16:36.29 |
| Robin_Watts | ooh. | 16:36.37 |
| sebras | Robin_Watts: http://pastebin.com/nVU070gY | 16:37.36 |
| | he also writes: take pretty much any document for which muclean doesn't outright crash during linearization (which also seems to happen occasionally) and run mubusy clean -l filename.pdf | 16:38.13 |
| Robin_Watts | If he has a file that crashes under linearisation, I would (grudgingly) like to see it :) | 16:38.58 |
| | (not that I don't believe it doesn't crash, more that I really hate this code :( ) | 16:39.17 |
| sebras | Robin_Watts: I pastebinned it. | 16:40.01 |
| Robin_Watts | yes, I have the file that asserts, thanks. | 16:40.25 |
| | I'd like to see a file that causes a crash. | 16:40.36 |
| sebras | oh the confusion. | 16:40.55 |
| | Robin_Watts: I see multiple uses of uninited values in valgrind on this file. | 16:41.49 |
| Robin_Watts | http://ghostscript.com/~robin/mupdf-thirdparty-2012-06-08.zip | 16:44.04 |
| | And I forgot to update the readme file. gah. | 16:44.36 |
| kens | The city map file, #37 the changing text, the text is vector data, not an image and not text | 16:48.09 |
| | The 'southGate' portion | 16:48.30 |
| | The 'Bath' is text | 16:48.35 |
| chrisl | That file is bonkers! :-( | 16:49.01 |
| kens | It is lying on top of a transparent region which may have some bearing | 16:49.30 |
| Robin_Watts | kens: yes, but I have no idea how changing thirdparty can have affected it. | 16:50.11 |
| kens | Robin_Watts : Me neither :-) | 16:50.21 |
| | Its definitely a progression though | 16:50.32 |
| Robin_Watts | Never mind, I'll do some more tests. | 16:50.36 |
| kens | OK I'm off for the night, goodnight all | 16:53.05 |
| chrisl | 'nite kens | 16:53.17 |
| Robin_Watts | sebras: ok. I can reproduce the assert locally. | 16:54.14 |
| sebras | Robin_Watts: my apologies. | 16:56.46 |
| Robin_Watts | I see the problem. | 16:57.03 |
| | It's because the file is already linearised. | 16:57.09 |
| | then opts->start == 1 | 16:57.18 |
| sebras | Robin_Watts: ah. | 16:57.29 |
| | Robin_Watts: mubusy clean -l http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_archives/PDFReference13.pdf crashes. | 17:00.53 |
| Robin_Watts | I was hoping for a somewhat smaller example :) | 17:01.33 |
| sebras | it's when it's resizing some array in page_objects_list_ensure | 17:01.38 |
| | Robin_Watts: alright. I'll try to find one. | 17:01.47 |
| Robin_Watts | but that may be enough. | 17:01.57 |
| chrisl | Robin_Watts: when you have a second, I've slightly changed your metro stuff for cups, can you just check you're happy with it: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=989488a1 | 17:10.15 |
| Robin_Watts | That looks good to me. | 17:11.02 |
| chrisl | Actually, I've just spotted a small mistake.... but thanks | 17:11.52 |
| sebras | Robin_Watts: in page_objects_list, the cap there it counts how many pages can at most be in the list, right? | 17:26.05 |
| | while the cap in each page object counts the number of objects in each page. | 17:26.17 |
| Robin_Watts | We have cap and max, right? | 17:26.28 |
| sebras | cap and len. | 17:26.34 |
| Robin_Watts | Right. cap is the malloced size. | 17:26.51 |
| | len is the number we have. | 17:26.54 |
| sebras | I'm more referring to that the cap and len are related to the object list and the page list respectively. | 17:27.00 |
| Robin_Watts | so len <= cap. | 17:27.05 |
| sebras | yes. | 17:27.08 |
| | and the len/cap in page_objects_list refers to the amount of _pages_. | 17:27.30 |
| Robin_Watts | page_objects_list contains a 1-per-page list. | 17:27.39 |
| sebras | yes. | 17:27.45 |
| Robin_Watts | page_objects is a list of all the objects on a page. | 17:27.49 |
| sebras | then you have a problem in page_objects_list_ensure. | 17:27.56 |
| | at least I think so. | 17:28.16 |
| | because you are resizing a page_objects_list to include a new page. | 17:28.43 |
| | did you mean to resize one page only in the list? | 17:29.01 |
| | otherwise you are not taking into account that each page has a variable sized objects array at the end. | 17:29.26 |
| | Robin_Watts: do you see what I mean? | 17:30.43 |
| Robin_Watts | No, but that may be me being slow. | 17:30.53 |
| sebras | what is page_objects_list_ensure() meant to ensure the size of? | 17:31.17 |
| | the entire list? or the list of objects for a single page? | 17:31.31 |
| Robin_Watts | page_objects_list_ensure ensures that a given page_object_list has at least n page_objects pointers in it. | 17:32.19 |
| sebras | right. | 17:32.35 |
| | but when you compute the new size you resize to. | 17:32.44 |
| | do you take each existing page_objects object list into account? | 17:32.57 |
| | there ought to be a loop in there somewhere to count the number of ints at the end of each page in the objects list. | 17:33.22 |
| Robin_Watts | I resize the array to: sizeof(**pol) + (newcap-1)*sizeof(int) | 17:33.58 |
| | sizeof(**pol) = sizeof(page_objects_list) | 17:34.12 |
| | i.e. the structure which includes 1 page_objects pointer. | 17:34.52 |
| | it shouldn't be sizeof(int), it should be sizeof(page_objects *) | 17:35.21 |
| | Does that make sense ? | 17:35.57 |
| sebras | Robin_Watts: yes. | 17:36.17 |
| | Robin_Watts: now it no longer crashes. | 17:37.53 |
| | Robin_Watts: though some consistency about sizeof(**pol) and sizeof (page_objects | 17:38.29 |
| | seems like it would have helped me understand. | 17:38.54 |
| Robin_Watts | yeah, sorry :( | 17:38.58 |
| sebras | also the order of factors for the multiplication may have helped. | 17:39.27 |
| | anyway. | 17:39.30 |
| Robin_Watts | I will try to update it when I figure out what's up with linearisation. | 17:39.39 |
| | I think the problem is basically that I didn't test linearising single page files :( | 17:39.52 |
| sebras | what do you mean with what's up? | 17:39.57 |
| Robin_Watts | My code is broken :( | 17:40.09 |
| sebras | mmm, linearizing pdfref11.pdf (which used to crash) never completes. well not fast anyway. | 17:40.45 |
| | it seems to be stuck in mark_all() somewhere. | 17:41.02 |
| | Robin_Watts: I have the linearisation code asserting on a multipage file as well. | 17:45.26 |
| Robin_Watts | Just let me be stuck in a single hell at a time, eh? :) | 17:45.52 |
| sebras | no? :) | 17:46.44 |
| ray_laptop | the 906 release doesn't show up on my branch -l | 18:07.35 |
| | is it supposed to ? | 18:07.41 |
| | Robin_Watts: seems that bothering with linearizing single page files can just be skipped | 18:08.36 |
| | sorry -- that linearizing can be skipped | 18:08.55 |
| sebras | Robin_Watts: I think I'm going to leave these 2000 lines of linearization goodness to some other day. | 18:12.04 |
| chrisl | ray_laptop: it might depend on the version of git you're using - I think older ones needed something like "git fetch origin/gs906" | 18:12.14 |
| ray_laptop | chrisl: I get fatal: 'origin/gs906' does not appear to be a git repository | 18:17.14 |
| | is that the right name ? | 18:17.38 |
| | chrisl: I was going to look at what the state of the release is (what you've pulled in and what you haven't) | 18:18.09 |
| chrisl | ray_laptop: hmm, try "git fetch origin gs906" | 18:19.38 |
| Robin_Watts | ray_laptop: It's *always* easier to look on the web :) | 18:20.26 |
| chrisl | http://git.ghostscript.com/?p=ghostpdl.git;a=shortlog;h=refs/heads/gs906 | 18:20.56 |
| ray_laptop | is there a way to correct Robin_Watts' log message in 5e82805 | 18:21.44 |
| | the default GS_SOFT_MAX_SPOTS is 10 (not GS_CLIENT_COLOR_MAX_COMPONENTS-4) | 18:22.12 |
| Robin_Watts | Not without rewriting all the hashes. | 18:22.12 |
| ray_laptop | Since this gets into the Changes and History9 of the release, it might confuse some | 18:22.44 |
| Robin_Watts | chrisl could do it for the release branch, but we can't do it for the general case. | 18:22.45 |
| ray_laptop | Robin_Watts: the git log isn't as important (IMHO) as the docs | 18:23.09 |
| Robin_Watts | The best we can do is to do another commit to do a whitespace change to that line and put the correct value in the commit message for that. | 18:23.30 |
| sebras | um... isn't that supposed to be git branch -r (for remote branches)? | 18:23.59 |
| ray_laptop | sebras: yes, thanks -- that was it | 18:24.37 |
| chrisl | ray_laptop, Robin_Watts: I can easily change History9.htm without worrying about git | 18:24.54 |
| ray_laptop | chrisl: it's also in Changes.htm and News.htm (and probably Details9.htm) iirc | 18:25.47 |
| | but some of those are built during the release from the logs | 18:26.26 |
| chrisl_ | ray_laptop: hmmm, not sure if this got through: A "bare" changelog from the previous release to the current release is created from the logs, and that used to be manually copied to the three files - I felt that was stupid, so I only do one, now. | 18:34.07 |
| ray_laptop | chrisl: thanks -- I didn't see the original | 18:35.37 |
| | chrisl: thanks -- less stupidity is a good thing | 18:36.15 |
| chrisl | ray_laptop: no, only in History9.htm | 18:36.59 |
| | No, none of them are | 18:36.59 |
| | A "bare" changelog from the previous release to the current release is created from the logs, and that used to be manually copied to the three files - I felt that was stupid, so I only do one, now. | 18:36.59 |
| chrisl_ | Oh my, strange things a'happening..... | 18:37.30 |
| ray_laptop | chrisl: better now ? | 18:39.55 |
| chrisl | Hope so.... | 18:40.07 |
| ray_laptop | messages did seem a bit out of order | 18:40.43 |
| | chrisl: so, what are we going to do about the OpenJPEG security fix ? | 18:41.30 |
| chrisl | ray_laptop: I don't know | 18:41.48 |
| ray_laptop | (does it even affect us ?) | 18:42.02 |
| chrisl | One of them doesn't, it's in the encoder - I'm not sure about the others | 18:42.31 |
| ray_laptop | chrisl: which one doesn't (to save me looking at that one) ? | 18:43.23 |
| chrisl | ray_laptop: I'll need to look it up.... | 18:44.23 |
| ray_laptop | chrisl: I would expect that 3358 _does_ affect us (j2k_read_sot) | 18:44.46 |
| chrisl | ray_laptop: I think the encoder patch is for one of the issues listed under "CVE-2009-5030" - unfortunately, that "issue" encompasses more than one upstream issue | 18:47.23 |
| ray_laptop | chrisl: despite the comment in 1499 that refers to a CMAP in a JPEG file, I suspect that also affects us since it looks like it actually is a JP@_CMAP in jp2_read_jp2h | 18:49.02 |
| | s/JP@/JP2/ | 18:49.13 |
| alexcher | chrisl: ray_laptop: I'll apply the patches to the currentr (1.4) version first. | 18:50.39 |
| ray_laptop | alexcher: great. Thanks. That'll let chrisl cherry pick it into the release (if all agree -- I think we should) | 18:51.16 |
| chrisl | I would like to, if it's feasible. I'm not too impressed with reporting issues, and leaving us to dig for the fixes - I'd much rather have linkes to the relevant upstream bugs..... | 18:53.13 |
| ray_laptop | chrisl: I agree, it seems rather lame not at least updating with the fix info in the report | 18:54.49 |
| chrisl | ray_laptop: what bothered me most was that, as can often happen, one security report actually turns into more than one ultimate bug | 18:56.21 |
| | ray_laptop: so I'll change History9.htm to read thus: http://pastebin.com/t1vsv1SG | 18:57.57 |
| ray_laptop | chrisl: fine with me | 19:01.10 |
| | I have to run now. bbiaw | 19:01.38 |
| chrisl | is done for today.... | 19:11.08 |
| sebras | Robin_Watts: I now see why you hate the hint stream. | 22:46.50 |
| | :-P | 22:47.07 |
| Robin_Watts | sebras: I've made some progress. Will try some more tomorrow. | 23:00.40 |
| sebras | Robin_Watts: sounds good. | 23:00.53 |
| | Robin_Watts: hint streams are overly complex. | 23:01.15 |
| Robin_Watts | Stupidly so. | 23:01.26 |
| | And very poorly documented. | 23:01.43 |
| | I had to resort to taking files to bits to understand them. | 23:01.54 |
| sebras | yeah, I can see why. | 23:02.03 |
| Robin_Watts | but it's not the hint stream that's at fault; it's the renumbering and ordering of objects. | 23:02.19 |
| sebras | in mupdf? yeah, I know. | 23:02.38 |
| Robin_Watts | The problem with the file I'm testing now was because of there being unused objects. | 23:02.41 |
| | but I'm getting there I think. | 23:02.45 |
| sebras | also, why is pdfref refering to "page 0" and that a document might not start with this page. | 23:03.44 |
| | does this refer to the page that is listed first offset-wise in the file? | 23:04.08 |
| | or the first page in the page tree? | 23:04.15 |
| | tor8: wow, I hadn't realized that is was possible to get to page 1 by pressing enter without and preceeding numbers. | 23:10.22 |
| Robin_Watts | Right page 0 means page 1. | 23:11.35 |
| | and you can supposedly indicate somehow that a pdf should open on not the first page. | 23:11.55 |
| | but it's in the implementation notes that Acrobat doesn't support it. Or something. | 23:12.11 |
| sebras | Robin_Watts: mmm, I wonder if anyone generating linearized pdfs can handle that case. | 23:12.19 |
| | Robin_Watts: how does a viewer know how many shared objects there are for each page? | 23:14.05 |
| | Forward 1 day (to 2012/08/07)>>> | |
IRC Logs