| | <<<Back 1 day (to 2014/11/13) | 20141114 |
| rayjj | chrisl_away: YUCK! IMH,but strongly held,O we need to totally rewrite the text operations in the PDF interpreter. What a rat's nest made of old spaghetti and feces | 00:29.20 |
| | each text operation needs a 'setup' a 'do it (i.e. show)' and a 'tear down'. All of the showfirst stuff was intended to do the setup, then set the Show proc to be the 'do it' proc, but there was no 'tear down | 00:31.39 |
| | so when I needed to encapsulate text operations for transparency (TextTransSetup ... TextTransTeardown) I put it in with setfillstate, but that gets processed on EVERY pair in the TJ array | 00:33.50 |
| | now I have to separate it out side of the Show proc | 00:34.41 |
| | but it should be this hard. Thus my statement that we need to rewrite this | 00:35.16 |
| | s/should/shouldn't/ | 00:35.29 |
| | I really don't think that job security comes from writing incomprehensible code :-/ | 00:36.12 |
| | the upshot is that it was probably me that made the change that caused the slowdown when I fixed the transparency for text (commit 21565d4) | 00:40.25 |
| | hmm... I guess it wasn't me. It's been that way for a L...O...N...G... time | 00:50.01 |
| mvrhel_laptop | ok cool bmpcmp is now working thanks marcosw | 01:47.58 |
| | ah there seems to be some page confusion with my images in the xps files | 01:58.42 |
| | will fix this tonight | 01:58.54 |
| | but def. some progressions from the rect fill | 01:59.19 |
| henrys | mvrhel_laptop: strange I expect rect fill to be slow but not wrong. Are they clipping issues I do need to fix some of that. | 02:11.36 |
| | ? | 02:11.45 |
| mvrhel_laptop | henrys: I suspect the diff is that the images end up getting interpolated | 02:12.26 |
| | this is default in xps | 02:12.33 |
| | so when we do rect fills there ends up being no interpolation | 02:13.08 |
| henrys | mvrhel_laptop: oh that makes sense. I looked at that bug about as much as I can without buying acrobat for windows... | 02:13.25 |
| mvrhel_laptop | henrys: ok. I am going to fix a few things tonight and tomorrow. I may take a quick look at it | 02:13.50 |
| henrys | mvrhel_laptop: I am guessing the viewer will not work on any page of that size. | 02:14.08 |
| mvrhel_laptop | right | 02:14.15 |
| henrys | MS viewer that is. | 02:14.18 |
| mvrhel_laptop | oh gawd. pdf14 clist device is installed in the way of the xps device for this file likely due to image with transparency. fun! | 05:55.04 |
| | looks like it is use_pdf14_accum | 05:58.31 |
| | I am probably going to need rayjj to walk me through this | 06:04.03 |
| | ok I see how this works | 06:10.30 |
| | hey that worked pretty good | 06:25.33 |
| | that is accumulating with the pdf14 clist device | 06:25.46 |
| | and with another cluster push heading to bed | 06:31.10 |
| chrisl | rayjj: (for the logs) once again, I pointed out a couple of years ago that the PDF interpreter text code was batsh*t crazy: anyone that thinks having a procedure called "Show" that calls a procedure called "showfirst", that calls a (different) procedure called "Show" is "good practice" is not classifiable as sane, IMHO...... and, frankly, it's especially bonkers in the context of Postscript | 08:01.23 |
| kens | would like ot say "I didn't write that" :-) | 08:02.01 |
| jogux | :-) | 08:02.29 |
| chrisl | I would be astonished if anyone would admit to writing it intentionally in its current form...... | 08:02.31 |
| kens | heads off to read the logs instead of email | 08:03.21 |
| chrisl | kens: I'm fairly sure Ghostscript will search for fonts at findfont time (but *not* CIDFonts) | 10:09.05 |
| kens | But only if it has the -sFONTPATH which includes the recently installed fonts presumably ? | 10:09.33 |
| | Or osme similar configuration infor, which they haven't told us they are doing | 10:09.53 |
| chrisl | Yes, I think so. You'd have to do something to tell gs to look in the \windows\fonts directory | 10:10.15 |
| kens | Yes, that's what I mean, I doubt of they are, and if they are, they aren't telling us, so how are we to know ? | 10:10.39 |
| | Given teh quality of the other reports, I doubt they are doing anythign at all, they just expect that because it works on WIndows (and Acrobat) Gs will 'just work' | 10:11.18 |
| chrisl | There's also the point that I don't know how tolerant we are of names - Acrobat may well have some partial matching heuristic, or other horrid crap | 10:11.53 |
| kens | I might also have pointed out that there are 9 missing fonts, and they've provided 3..... I've no idea if the ones they have provided are ht ones used at those points in the PS file. | 10:13.17 |
| chrisl | And the Windows installer does not automatically add the \windows\fonts folder to the font search path | 10:15.34 |
| kens | Hmm, so does it add the fonts it finds there infividually ? | 10:17.39 |
| | Or just doesn't add them at all ? | 10:17.48 |
| chrisl | Doesn't add them at all | 10:18.10 |
| kens | Well in that case they *really* need to tell us what they are doing now to get fonts loaded | 10:18.42 |
| | Especially since they are using GS as a library and using the API I believe | 10:19.08 |
| chrisl | The installer will add mappings for CIDFont substitutions *if* you ask it to, but nothing for fonts | 10:19.46 |
| kens | RIght, fair enough then | 10:19.56 |
| | Aaron really should know better by now ising a support query..... | 10:20.30 |
| chrisl | "It broke.... you fix" | 10:21.05 |
| Guest40885 | Hello. Could someome please help me with "-r" flag for mupdf.exe on windows? | 10:22.22 |
| kens | What -r flag ? | 10:23.28 |
| chrisl | -r sets the resoution | 10:24.10 |
| Guest40885 | right | 10:24.16 |
| kens | WIht MuPDF ? Really ? | 10:24.22 |
| Guest40885 | one moment il find it in man | 10:24.32 |
| chrisl | Well, it does on Linux...... | 10:24.41 |
| kens | Hmm, doesn't seem to do anythign for me on WIndows | 10:24.52 |
| Guest40885 | only on linux? | 10:24.59 |
| | it is not intended for win? | 10:25.08 |
| chrisl | I thought the options were the same.... maybe it doesn't do anything for the viewer | 10:25.33 |
| Guest40885 | Unfortunately I cant make it work. | 10:26.05 |
| chrisl | what version of mupdf are you using? | 10:26.20 |
| kens | If I use it with the current Windows example mupdf.exe it tells me it can't open the document | 10:26.22 |
| | THat's 1.6 for me | 10:26.27 |
| chrisl | strange, with mupdf-x11 I can set the resolution with -r | 10:26.48 |
| Guest40885 | the same storyfor me | 10:26.51 |
| kens | chrisl, you know the various example have different capabilities. | 10:27.26 |
| Guest40885 | mupdf.exe -r 120 some.pdf | 10:27.51 |
| chrisl | kens: I thought a fair amount of the basics were common | 10:27.54 |
| Guest40885 | I'am using 1.6 | 10:28.08 |
| chrisl | I didn't have a space between the -r and the value | 10:28.23 |
| kens | Well the library is the same, and basic display is the same, but other stuff, I think not No outline view on WIndows/Linux for example | 10:28.29 |
| | tor8 would know for sure if he were awake :-) | 10:28.47 |
| | Anyway, as far as I can tell, -r doesn't work with the WIndows sample code, and never has | 10:29.27 |
| Guest40885 | Without space I got the same error - "cannot open document" | 10:30.29 |
| chrisl | Yep, the windows app doesn't handle -r - sorry | 10:30.51 |
| Guest40885 | ok thanks for your assistance! | 10:30.55 |
| kens | I believe it is parsing the -r as a filename | 10:30.55 |
| chrisl | It seems like a strange omission..... | 10:32.47 |
| Guest40885 | very sad - 72 to small for my eyes. will continue to press + twice, after file opening | 10:32.52 |
| kens | It seems odd to me, but then I didn't write it :-) | 10:32.57 |
| chrisl | Guest40885: You can open an enhancement request - it would probably not be massively hard to add it | 10:33.31 |
| Guest40885 | Thank you! I'll do that | 10:34.02 |
| kens | chrisl FWIW if I add -sFONTPATH to point at a directory with the fonts the customer supplied, gs uses them for Swiss721BT-BoldCondensed, CXPiFont1General and DGADSymbolicLightout.pdf | 10:34.21 |
| tor8 | kens: what? me? awake?! | 10:34.55 |
| kens | However, when I look at the outptu PDF file, teh area of concern is clipped out | 10:34.58 |
| | tor8 :-) | 10:35.03 |
| chrisl | kens: "clipped out"? Then why do they care if the fonts are missing?? | 10:35.31 |
| tor8 | the mupdf windows viewer doesn't process arguments the same way as the x11 one | 10:35.46 |
| | it only supports -p for passwords | 10:35.56 |
| | did I mention how crusty the old viewer code is? | 10:36.11 |
| kens | I have no idea, presumably this relates to one of their other 'problems' with this file, that it is drawn on A4 (or possibly Letter) presumably because it does not execute a setpagedevice with a /PageSize | 10:36.16 |
| chrisl | tor8: I actually stuff like command line args was common to the win32 and x11 maps - silly me! | 10:36.50 |
| tor8 | chrisl: yeah, silly you! someone apparently added command line processing to win32 (wasn't me! or if so, I don't remember it!) to handle -p | 10:37.25 |
| kens | OK if I make the media FIXED and large enough I can see the area they are complaining about, and the fonts are now rendered correctly. SO the answer is 'you need to tell GS where your fonts are' | 10:37.43 |
| tor8 | I just remember looking at the WinMain stuff and saying eff it | 10:37.59 |
| chrisl | tor8: yeh, I looked at the code, which is why I figured it would be trivial to add -r to it | 10:38.09 |
| | kens: maybe it should be using a different bounding box? | 10:39.09 |
| kens | chrisl its not an EPS, and it appears not to execute a media request, why should we do anythign except use the default ? :-) | 10:39.44 |
| chrisl | Oh, I thought it was a PDF, sorry..... | 10:40.05 |
| kens | Also the DSC comment says BoundingBox: (atend) and doesn't upply one | 10:40.16 |
| | As usual, it claims to be DSC 3 compliant, and isn't | 10:40.41 |
| chrisl | Of course, this is one of the things that annoys me: on Linux/Unix, we'd probably find the font(s) without additional user input, because of fontconfig..... | 10:42.02 |
| kens | Yes, probably. | 10:42.34 |
| | Of course we could retrieve the WIndows font directory easily enough and automagically add it to the search path | 10:43.03 |
| | But I like the fact that this doesn't happen automatically personally | 10:43.20 |
| Guest40885 | Just in case, as I already disturbed you. Is it possible somehow to use Russian for searching on windows in Mupdf? | 10:43.29 |
| kens | You can then have different font setups | 10:43.32 |
| | Guest40885 : I thought it used Unicode for searches | 10:44.09 |
| chrisl | Yeh, I was thinking the opposite - we shouldn't be using fontconfig by default. So a default configuration would give consistent results on both Windows and Linux | 10:44.34 |
| kens | (or am I confused with Acrobat.....) | 10:44.35 |
| | chrisl hard call, one way is nice and easy for users, the ohter is more configurable. Do we want to be Apple or Linux ? :-) | 10:45.22 |
| chrisl | kens: I'd like to be a compliant Postscript rip, at least by default.... and Postscript is *supposed* to give consistent results wherever you use it | 10:46.26 |
| kens | Yeah, but this is Ghostscript we're talking about...... | 10:47.16 |
| tor8 | chrisl: yeah. it just hasn't been done | 10:47.59 |
| | chrisl: all that stuff *should* have been put in pdfapp_init | 10:48.32 |
| Guest40885 | kens: Unfortunately when I change lang to Russian it does not print anything - and send empty string to the search engine | 10:48.51 |
| chrisl | tor8: maybe the wchar handling makes that more problematic? | 10:49.08 |
| kens | One for tor8 to answer | 10:49.10 |
| tor8 | chrisl: it does, but I think robin managed to fix that somehow for the mutools | 10:49.36 |
| | Guest40885: sorry. the text input and search for the win32 (and x11) viewer is strictly latin-1 :( | 10:49.59 |
| | it's a font drawing and input issue for x11, and the win32 viewer suffers the same limitations | 10:50.46 |
| Guest40885 | tor8: Thanks ok I got it! How do you think make it sense to open Feature Request for this functionality? | 10:53.06 |
| Robin_Watts | Guest: The existing mupdf viewers for win32 and linux will not be updated. | 10:55.30 |
| | but we have a new viewer (an update of gsview) coming soon that should work. | 10:55.52 |
| Guest40885 | Good news. Thank a lot! All of you! | 10:58.19 |
| tor8 | Guest40885: and there's also a new bare-bones viewer coming a bit later | 12:57.22 |
| | so the existing win32 and x11 viewers won't be updated | 12:57.45 |
| Guest40885 | tor8: thank you, I got the point. I'll try to modify the code myself =) at least for parsing -r or just change the default 72 to 120 | 13:02.06 |
| tor8 | Robin_Watts: not the fastest layout, but I'm still surprised my current inefficient code still manages to lay out 1500 pages per second | 13:48.27 |
| Robin_Watts | nice. | 13:48.40 |
| | Do you cope with bidirectional text? :) | 13:48.49 |
| tor8 | so a second or two loading time for a typical ebook, even if we greedily lay out the whole book at start, shouldn't be too bad | 13:49.12 |
| | hell no :) | 13:49.20 |
| | but I have the data structures set up so that TeX style dynamic programming optimization of line breaks will be possible | 13:49.46 |
| Robin_Watts | Having just struggled through that with the epage code, I am in a position to offer hints if you are interested. | 13:49.52 |
| | You always lay out left to right? | 13:50.11 |
| tor8 | Robin_Watts: I will keep that in mind, but I expect you to have forgotten it all by the time I get around to implementing BiDi text layout :( | 13:50.28 |
| nsz | is there a format where you need to do line wrapping at render time? | 13:50.30 |
| tor8 | nsz: EPUB is structured so that each chapter is usually in its own HTML file | 13:50.52 |
| | or split along forced page breaks | 13:50.59 |
| nsz | aah html | 13:51.03 |
| tor8 | so you can lazily just lay out one chapter at a time | 13:51.10 |
| Robin_Watts | nsz: If you layout to a display list and then repeatedly render than display list you never layout at render time for any format. | 13:51.32 |
| tor8 | but MuPDF has a fairly big assumption that you know how many pages a document is when you open it, being based on fixed page layout formats like PDF | 13:51.40 |
| chrisl | nsz: in terms of PDLs, PCL does line wrapping at interpretation time..... | 13:51.51 |
| Robin_Watts | You may well need to redo that layout to display list phase if you want to reflow to a different page zoon etc. | 13:51.54 |
| tor8 | hence we need to either lay out the entire book when we open it, or add a dual layer of 'chapters' that contain a fixed number of pages | 13:52.26 |
| | that can be determined when the chapter is navigated to | 13:52.47 |
| | and it gets messy... | 13:52.51 |
| | but if we can lay out the entire book in a reasonable amount of time at load I won't bother with that | 13:53.23 |
| | just let it take a second or two to open a big fat book | 13:53.34 |
| | or make sure our viewers can cope with fluctuating page number counts | 13:53.48 |
| | and then lay out as you navigate | 13:53.57 |
| nsz | i see | 13:53.58 |
| tor8 | which is probably a better approach overall, and less invasive than adding a chapter abstraction | 13:54.37 |
| | but it does mean having to lay out the whole book if jumping to a page towards the end | 13:55.00 |
| nsz | html does not work well with page based medium i guess | 13:56.08 |
| | is epub usually viewed page-by-page or continously? | 13:56.23 |
| Robin_Watts | epub is targetted at ebook readers. Those are all page based. | 13:57.35 |
| nsz | i see | 13:57.43 |
| | i guess continous text is not possible without a lot of ram | 13:58.11 |
| | or you need small chapters or something | 13:58.18 |
| tor8 | nsz: ebook readers tend to be e-ink, which has ridiculously slow screen refresh rates | 13:58.54 |
| | so you really don't want continuous scrolling on e-ink | 13:59.04 |
| | and pages are a better UI for reading text than continuous scroll. less risk of accidentally nudging the scroll bar and getting lost. | 13:59.42 |
| nsz | hm so maybe html5 should have added page break annotations | 14:00.34 |
| tor8 | css 2.1 has page break annotations | 14:00.46 |
| nsz | ah i didnt know that | 14:00.57 |
| | but css is a mess as far as i can tell | 14:01.06 |
| tor8 | page-break-before: auto/always/avoid | 14:01.10 |
| | it's a royal mess for anything but the simplest use cases | 14:01.23 |
| | for styling web pages from the early-mid 90's (before the whole <blink> tag, animated "under construction" gif, geocities heyday) it would work great | 14:02.20 |
| | today, people go through terrible contortions with CSS just to avoid using tables to do fancy web site design | 14:03.04 |
| | because "tables are bad, mmkay! now here, have some more kool-aid." | 14:03.17 |
| nsz | html tables for layout have their own warts: i looked at w3m table rendering code once, it uses linear equation solver with lot of heuristics to get similar column widths as netscape | 14:09.01 |
| | you need to parse the entire table to determine the right widths and the table inside table case adds recursive constraints | 14:09.45 |
| | html layout methods are not successful designs | 14:13.28 |
| henrys | kens: thanks for looking at that. | 14:23.36 |
| kens | WHat did I look at ? | 14:23.45 |
| kens | is confused today.... | 14:23.54 |
| henrys | the scaled page that prints as letter | 14:25.39 |
| kens | Is that the one from Aaron ? | 14:26.03 |
| | WOw, I'mglad I'm not travelling for a flight today: | 14:26.19 |
| | http://www.bbc.co.uk/news/uk-england-surrey-30049739 | 14:26.19 |
| henrys | http://bugs.ghostscript.com/show_bug.cgi?id=695680 | 14:26.56 |
| kens | Oh right, I totally forgot about that one :-) | 14:27.18 |
| | I figured I'm probably one of the few people with full Acrobat and a Windows PC with the MS XPS writer installed | 14:28.54 |
| chrisl | kens: I wonder how we, as a nation, have forgotten how to build and fix roads :-( | 14:33.51 |
| kens | Its an impressive one though isn't it ? :-) | 14:34.12 |
| | THe M25 truly is the road to hell | 14:34.24 |
| chrisl | Well, more accurately, it's the road to itself..... | 14:34.46 |
| kens | Close enugh | 14:35.00 |
| henrys | kens: 6 hours is a long time ;-) | 14:35.28 |
| jogux | chrisl: we didn't forget, we just outsourced it to the cheapest guy, who turned out not to know :-( | 14:35.34 |
| kens | Ian suggested it was a job creation scheme.... | 14:35.48 |
| chrisl | jogux: yeh, but now the people who did know have been out of work so long, they've now forgotten | 14:36.30 |
| | Also, round here, none of the contractors seem to realise that a drain should go at the lowest point - so practically every road floods..... | 14:38.58 |
| Robin_Watts | chrisl: The problem is that drains etc have to be supported by concrete, so that when the rest of the road subsides, they are the only bit that doesn't sink... | 14:44.58 |
| jogux | chrisl: :( | 14:46.30 |
| chrisl | Robin_Watts: as unforgivable as that would be, this is worse - several were actually re-constructed that way..... | 14:46.42 |
| | Robin_Watts: I'm not overly optimistic about Caterham at this stage :-( | 14:48.17 |
| Robin_Watts | chrisl: Yeah. I think Marussia are the more financially viable team, but they don't have a crowd funding thing. | 14:48.55 |
| kens | Crumbs, there's a warning from GS I've never seen before.... | 14:49.23 |
| chrisl | Oh, come on, kens you can't us hanging like that...... | 14:50.35 |
| kens | Oh sorry.... | 14:51.09 |
| | PDF14 device push/pop out of sync | 14:51.09 |
| | I suspect its a debug only message | 14:51.22 |
| chrisl | Nope, I've never seen that either | 14:51.49 |
| | Robin_Watts: the Caterham total has jumped quite a lot in the last few hours, but it's still a fair way to go | 14:51.56 |
| kens | Its htis bug Marcos raised for Ray | 14:52.02 |
| | I have a feeling this file was incorrect before, Ray's change just makes it incorrect in a new and excitiingly different way | 14:52.28 |
| chrisl | Presumably with the SMask fix? | 14:53.11 |
| kens | Yes, the file is OK in Acrobat (of course), the pdfwrite outptu file that is of course | 14:53.38 |
| chrisl | Phfft, Acrobat, who would believe that...? | 14:54.14 |
| kens | Actually it looks like 9.14 was happy with the file no matter what | 14:54.49 |
| | The strange thing is that the file doesn't seem to trigger Ray's changed code for me :-( | 14:55.08 |
| chrisl | Possibly the warning is wrong? | 14:56.10 |
| kens | I'm just rertying with a clean build of master | 14:56.40 |
| | The master and 9.15 files differ in size by 30 bytes, which might be nothing | 14:57.15 |
| | Well, I get the same warnign from 9.14 and the output is similarly broken | 14:58.03 |
| | THa tis PDF->PDF using 9.14 then render the resulting PDF with 9.14 | 14:58.22 |
| | Drat, no I used 9.15 | 14:58.34 |
| | Oops | 14:58.37 |
| | 9.14 renders the PDF produced by 9.14 correctly, and also the PDF produced by master correctly. Master renders both PDF files incorrectly (in the same way) | 15:00.12 |
| | So I don't 'think' the problem is with pdfwrite | 15:00.39 |
| | Uncompressed the 2 PDF files still only differ by 30 bytes, the producer and so on fields are different, there's some slight difference in the embedded XML (I seem to recall someone raising a report on that recently, so its probably a fixed bug) | 15:02.47 |
| | But otherwise the files are identical. So it seems Ray's change to the PDF interpreter has indeed broken something :-( | 15:03.40 |
| | I'm guessing this is what results in the PDF14 warnings about being out of sync. Presumably we are pushing one of these special transparency masks which is supposed to pop the existing SMask, and its being done inappropriately | 15:05.00 |
| chrisl | There are so many routes through some of that code...... | 15:06.00 |
| kens | Yeah, I'm just about to start unwinding my ball of string :-( | 15:06.17 |
| | Well,the original PDF file doesn't trigger Ray's change, the one output by pdfwrite does. That doesn't (of course) mean that the pdfwrite output is invalid, just 'different'. | 15:15.58 |
| chrisl | Odd that pdfwrite would add an SMask? | 15:17.50 |
| kens | Odd, but by no means impossible, we all know that it has to rewrap stuff, it may have written an ExtGState with a default setting or something | 15:18.29 |
| | Yes, object 39 is an ExtGstate whose only contents are /SMask /None | 15:19.22 |
| | And that triggers Ray's alteration which causes bad things to happen | 15:19.40 |
| chrisl | Yeh, that sounds nasty...... | 15:20.06 |
| kens | I'm not entirely sure why, but then I didn't do the analysis on this code in the first place. I may well leave this to Ray yet. | 15:20.52 |
| chrisl | Is the ExtGstate used more than once? | 15:21.27 |
| kens | Not sure, give me a moment and I'll check | 15:21.36 |
| | That seems to be a yes | 15:21.54 |
| | Once in a Form XObject | 15:22.11 |
| | THe other time is in the page | 15:22.41 |
| chrisl | So, it could be that the code isn't spotting the /SMask is /None and thinks it needs to "unset" the SMask later on? | 15:22.44 |
| kens | Beats me :-) | 15:22.55 |
| | I'm sort of suspicous the problem is the form though | 15:23.14 |
| | OK it only actually gets used in teh Form, it looks like we add it to the page resoruces as well, because the form is used on that page. I don't think that's strictly necessary, but it shouldn't cause any harm either | 15:24.25 |
| | OK it seems there is a SMask in force, before we set the /None. | 15:26.08 |
| | And there's a new one set after the one we zapped it seems. | 15:26.53 |
| | It looks like hte problem is that we are not executing Ray's change when we get a /SMask /None because the current SMask is //null, this seems to seriously confuse the PDF14 compositor, though I'm not really clear on why | 15:37.40 |
| | Hmm, no that's not the whole story. If I remove that test then the fiel completes without error, but draws a blank page :-) | 15:39.04 |
| chrisl | I guess Ray's change handles the case when the incoming ExtGstate has no SMask, but not an SMask of /None.... | 15:39.55 |
| kens | I admit I'm a bti confused by this stuff | 15:40.18 |
| | The code explicitly looks for an SMask of /None | 15:40.37 |
| | Removing Ray's code does resolve the problem completely though :-( | 15:42.07 |
| | We only execute the change Ray made once, so its that single execution that causes the problem | 15:43.06 |
| rayjj | goes to check the logs ... | 15:44.55 |
| chrisl | It has to be related to loading an ExtGstate with a "real" SMask, and then loading one with an SMask on /None (rather than just no having one) | 15:45.03 |
| | kens: what happens if you remove the /SMask /None line from the ExtGstate? | 15:45.26 |
| kens | Well, I think its more to do with loading a real SMask, then a /None, then another real SMask | 15:45.26 |
| | I was going to try that, justa moment | 15:45.38 |
| | Without that line both Acrobat and GS display the file correctly | 15:46.38 |
| | Well, approximately anyway, there are no obvious gross errors | 15:47.11 |
| chrisl | Well, that at least narrows the issue a little | 15:47.20 |
| rayjj | kens: so you are referring to the change circa line 460 in pdf_draw.ps ? | 15:49.33 |
| kens | rayjj yes, I think so | 15:49.46 |
| rayjj | based on SoftMask being //null | 15:49.55 |
| kens | THis commit ea6290b302598f13e7fb4c29aff73657989e693d | 15:50.03 |
| | THe bug report raised by Marcos overnight | 15:50.19 |
| | #695683 | 15:50.30 |
| | Without that change, the PDF file produced by pdfwrite works in GS, with it, it deos not. pdfwrite is adding an /ExtGState with a /None SMask (I'm not certain why) and that is causing the PDF14 compositor to get cross. | 15:51.25 |
| | Even if pdfwrite is incorrect to add the /None ExtGState, I would not expect this kind of problem. | 15:51.49 |
| rayjj | kens: do you want to play with it more, or throw it to me ? | 15:52.02 |
| kens | rayjj you may as well look at it I think (its assigned to you anyway), I'll be out of time soon anyway and I confess I don't really understand what's going on here | 15:52.32 |
| rayjj | I have to take my son to school soon | 15:52.34 |
| | kens: OK. Thanks for the initial sleuthing | 15:52.55 |
| kens | More like initial confusion :-( | 15:53.03 |
| rayjj | kens: saves me time getting confused ;-) | 15:53.23 |
| kens | Well, the object number causing the problem is in the log, as well as the poking it with a blunt stick approach to debugging | 15:53.59 |
| | It 'might' be helpful | 15:54.10 |
| chrisl | rayjj: I have one think for you while I'm here..... are still poking at the clist temp files stuff? | 15:55.01 |
| | s/think/thing | 15:55.09 |
| rayjj | chrisl: on the clist tempfiles, I found one segfault caused by using the fname after we free it -- switching the order to close the file first, then free the fname resolved that one | 15:56.22 |
| chrisl | Since we now (for BGPrint) have to hold the clist file name(s) in a couple of places, I was thinking it would make sense to have the file name stored in the file "object", and add a "get_file_name" or similar method (like the stream code has) | 15:56.46 |
| | rayjj: ^^ | 15:56.50 |
| rayjj | chrisl: but that drained to pond to where I have another trickier segfault | 15:56.52 |
| | chrisl: the problem is that we (paul) use the the fname to find our special file structure | 15:57.53 |
| chrisl | Ah, that's a pain :-( | 15:58.22 |
| rayjj | the fname contains the pointer specially encoded. But 'clist_file_ptr' is supposed to be opaque, so we might be able to do a little surgery and make your idea work | 15:58.56 |
| | chrisl: I have to run now. bbiaw | 15:59.09 |
| chrisl | rayjj: bye | 15:59.15 |
| Guest40885 | #kens | 16:39.28 |
| kens | ? | 16:39.32 |
| Guest40885 | sorry | 16:39.41 |
| kens | :-) | 16:39.46 |
| | Night all, have a good weekend | 17:18.30 |
| mvrhel_laptop | bbiaw | 17:24.35 |
| rayjj | OK. I have an optimization to PDF text handling that speeds up the 16p test file from cust 532 on my laptop by 1.6x going out to 72 dpi pbmraw (thus mostly parse time) | 19:06.15 |
| | starting a regression run now... | 19:06.30 |
| Robin_Watts | rayjj: Nice. Let's hope it passes :) | 19:06.43 |
| rayjj | Robin_Watts: agreed. I had a candidate (that I screwed up) last night that showed some problems. This one passes some of the problem files as well | 19:07.39 |
| | Great. Down to 1 difference in 3217 files (ppmraw lores gs) | 20:27.56 |
| | OK, I think I can commit this. The PLRM-3rd is no slower and the sample file is much faster and no regressions. | 20:50.45 |
| | pushed the commit, and Len notified. Next I'll look at caching the font object across pages as discussed with chrisl and kens yesterday | 20:53.13 |
| sebras | tor8: I checked though the new droid font from android. only a couple of changed glyphs U+3A34 was apparently fixed and U+2654 was swapped with U+265A as was U+2655 with U+265B | 23:56.09 |
| | Forward 1 day (to 2014/11/15)>>> | |
IRC Logs