| | <<<Back 1 day (to 2014/02/03) | 2014/02/04 |
| kens | thanks chrisl | 08:24.20 |
| | I see it here now | 08:24.27 |
| | I wonder why Miranda won't work though | 08:24.35 |
| chrisl | Maybe Miranda looks like the source of the ddos attack? | 08:25.02 |
| kens | Oh, I didn't think of that one | 08:25.41 |
| Robin_Watts | Morning tor8. | 12:28.04 |
| tor8 | hi Robin_Watts | 12:28.08 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=06fe137f323d8293d8e1823d92c885d7670efe4c | 12:28.17 |
| tor8 | did you see my burbling about word line breaking yesterday or did that get lost in the irc network troubles? | 12:28.23 |
| Robin_Watts | That's the reworked path extraction. | 12:28.28 |
| | tor8: I saw something... you suggested that office linebreaked differently according to the selected printer ? | 12:28.50 |
| | That's horrible, and oh so possible. | 12:29.04 |
| kens | It definetly does | 12:29.08 |
| tor8 | Robin_Watts: yeah. that. | 12:29.18 |
| Robin_Watts | so how the hell are we ever supposed to match it? | 12:29.22 |
| tor8 | Robin_Watts: by reading out the currently selected printer (I believe that's saved in the doc file? if not... there's no hope in hell) | 12:29.48 |
| kens | you cna only match it for a specific printer | 12:29.52 |
| tor8 | but yeah, it's a mess alright! | 12:30.00 |
| Robin_Watts | tor8: The above patch gets the outlines unscaled, and then applies the transforms to them. | 12:30.33 |
| | The bmpcmps are all trivial changes, with a few progressions thrown in there. | 12:30.56 |
| | previously corners of chars were being chopped off slightly due to the bbox inaccuracies. | 12:31.18 |
| | and it makes the SVG output look much better. | 12:31.28 |
| tor8 | Robin_Watts: yeah, that looks just like what I had in mind. | 12:32.25 |
| | we haven't used "const float x = ..." before, is there any specific benefit to it? | 12:32.53 |
| Robin_Watts | tor8: It's readable, and it should (I hope) stop the compiler recalculating things. | 12:33.27 |
| | Which instance were you looking at? | 12:33.34 |
| tor8 | recip | 12:33.49 |
| Robin_Watts | right. | 12:33.58 |
| tor8 | fz_bound_ft_glyph, the recip and strength floats are const | 12:34.03 |
| | but they depend on a non-const scale | 12:34.14 |
| Robin_Watts | oh, the scale should be const too, probably. | 12:34.31 |
| tor8 | I think in this case, C (as opposed to C++) won't actually optimize any better just prevents further writes to the variable | 12:34.41 |
| Robin_Watts | The key thing with recip was that I didn't want to do 4 divisions. | 12:35.19 |
| | FP division much more expensive than FP muls. | 12:35.33 |
| tor8 | I am a big const convert, but here I don't really see the need for it. mind you, if you have a good argument, I'm all for more consts. | 12:35.46 |
| Robin_Watts | The const is just a readability thing for humans really. | 12:35.58 |
| tor8 | the recip thing is a common "trick", no argument there | 12:36.00 |
| | I can buy that argument | 12:36.06 |
| | but then scale probably ought to be const as well :) | 12:36.16 |
| Robin_Watts | so probably I should make the scale const. | 12:36.20 |
| | yeah. | 12:36.21 |
| | I will make that change. | 12:36.35 |
| tor8 | Robin_Watts: in fz_outline_ft_glyph there are two issues | 12:37.54 |
| | one which I just thought of | 12:37.57 |
| Robin_Watts | ok. | 12:38.27 |
| tor8 | 1) you call FT_Set_Char_Size needlessly (since you pass NO_SCALE to FT_Load_Glyph) | 12:38.34 |
| | 2) dynalab fonts will break, since they actually need hinting. but that was broken before as well. | 12:38.50 |
| Robin_Watts | tor8: The docs seem to suggest that I should call FT_Set_Char_Size anyway. | 12:39.03 |
| | If the font is âtrickyâ (see FT_FACE_FLAG_TRICKY for more), using FT_LOAD_NO_SCALE usually yields meaningless outlines because the subglyphs must be scaled and positioned with hinting instructions. This can be solved by loading the font without FT_LOAD_NO_SCALE and setting the character size to âfont->units_per_EMâ. | 12:39.28 |
| | or am I reading that wrong? | 12:39.50 |
| tor8 | Robin_Watts: the docs suggest to set the character size to face->units_per_EM and load as normal for FT_FACE_FLAG_TRICKY (aka dynalab) fonts | 12:39.54 |
| | yeah, that sentence | 12:40.05 |
| | but that implies not using FT_LOAD_NO_SCALE at all | 12:40.14 |
| Robin_Watts | Right. I hadn't got that implication. | 12:40.24 |
| | but you may be right. | 12:40.30 |
| tor8 | so if we change the scale to the units_per_EM and leave the FT_Load_Glyph unchanged, we should still get the desired fix | 12:40.51 |
| Robin_Watts | But for TRICKY fonts we should enable hinting then ? | 12:40.53 |
| tor8 | and we have our own TRICKY flag set (since the freetype one misses a number of dynalab fonts) | 12:41.36 |
| Robin_Watts | as otherwise we'll still get meaningless outlines ? | 12:41.47 |
| tor8 | there is a fz_font->ft_hint flag we eset | 12:42.20 |
| Robin_Watts | ok, for fonts that are TRICKY (or that we recognise as tricky) we should enable hinting ? | 12:42.29 |
| tor8 | in do_ft_render_glyph you can see how it is used | 12:42.40 |
| | FT_Load_Glyph(face, gid, FT_LOAD_NO_BITMAP | (font->ft_hint ? 0 : FT_LOAD_NO_HINTING)) | 12:43.31 |
| | or something to that effect | 12:43.35 |
| | though I think we ought to be able to just drop the NO_BITMAP flag since we never load bitmap fonts | 12:43.54 |
| | I was just worried about bitmap fonts coming through fontconfig (or freetype picking up an embedded bitmap in the truetype) | 12:44.26 |
| | or just use the NO_SCALE for non-tricky | 12:46.13 |
| | so if (ft_hint) FT_LOAD_NO_BITMAP else FT_LOAD_NO_SCALE | 12:46.44 |
| | Robin_Watts: btw, did you see the new scary thing Adobe is doing this summer? they're deprecating the Adept DRM and forcing everybody to upgrade to some new DRM scheme... | 12:48.18 |
| Robin_Watts | I don't even know about Adept. | 12:48.43 |
| tor8 | that's going to be very popular with owners of older devices that are unlikely to see any more firmware upgrades. | 12:48.44 |
| Robin_Watts | I'm not up on their DRM schemes. | 12:48.52 |
| tor8 | Robin_Watts: Adept is the name of the current Adobe Digital Editions DRM | 12:48.54 |
| | the one that's been cracked since ages | 12:49.04 |
| Robin_Watts | ah, ok. | 12:49.12 |
| tor8 | basically anybody selling DRMed ebooks outside of the big shops (amazon, itunes, nook) use it | 12:49.45 |
| Robin_Watts | OK, so I'll try for the if (ft_hint) FT_LOAD_NO_BITMAP else FT_LOAD_NO_SCALE solution. | 12:49.59 |
| tor8 | Robin_Watts: yeah. http://bugs.ghostscript.com/show_bug.cgi?id=691997 has a dynalab font if you want to test | 12:52.35 |
| Robin_Watts | Can I add that file to the tests dirs? | 12:56.22 |
| | can't see any reason why not. | 12:56.27 |
| tor8 | Robin_Watts: go ahead | 13:00.37 |
| Robin_Watts | shiny! | 13:20.33 |
| | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=639b772c69531d4c4287249143a46b9512f02be5 | 13:34.51 |
| tor8 | quanitisation typo | 14:06.58 |
| | Robin_Watts: ^ | 14:07.02 |
| Robin_Watts | OK. Other than that? | 14:07.35 |
| tor8 | other than that LGTM | 14:08.42 |
| Robin_Watts | thanks. pushed. | 14:10.14 |
| tor8 | paulgardiner: a handful more pdf-util.js fixes on tor/master. I'm running them on a clusterpush now; hopefully they don't break anything. | 14:25.35 |
| henrys | paulgardiner, kens: I started to question the credibility of the program when the people weren't choosing the pink donut | 14:30.21 |
| | I watched in on youtube - does bbc just give away their programs? I thought most illegal stuff was swept from youtube? | 14:31.21 |
| paulgardiner | henrys: ah you found a copy then. Yes, I found that part difficult to believe | 14:31.31 |
| henrys | interesting program nonetheless | 14:32.13 |
| paulgardiner | There's a 720p copy here http://download.glidos.net/Horizon%20-%20Sugar%20v%20Fat.mp4 if anyone wants it. | 14:33.30 |
| | I'll leave it there for a few days. | 14:33.57 |
| kens | henrys they don't give them away, but we can get them | 14:34.20 |
| | free here of course | 14:34.22 |
| | tor8 are you using Miranda at the moment ? | 14:34.43 |
| tor8 | henrys: I gather it's much like most national tv here in europe; it's free but only if your IP geo-location thing comes from the correct country | 14:35.20 |
| | kens: not for IRC, but for everything else | 14:35.34 |
| | I use Xchat for IRC | 14:35.37 |
| paulgardiner | henrys, kens: what I was left wondering was whether everything we eat counts as a fat/sugar mixture (seeing as they really meant carbs by sugar a lot of the time). E.g., cheese sandwich, pasta bake. | 14:35.40 |
| kens | Ah, OK. I can't get Miranda to work on IRC suddenly | 14:35.53 |
| tor8 | kens: might your troubles be because of NickSrv maybe? | 14:36.03 |
| kens | NickServ is working fine with chatzilla. Miranda won't even connect | 14:36.25 |
| tor8 | kens: give me a minute, I can try connecting with miranda and see if it works for me. | 14:36.54 |
| kens | Not to worry, just curious because it was OK until yesterday | 14:37.14 |
| | And I've got out of the habit of using Chatzilla | 14:37.32 |
| | I'm confused, when's the meeting ? | 14:38.19 |
| henrys | paulgardiner: I thought the takeaway was don't eat 50/50 stuff and I did look a bit and that does stand up to what your grandmother told you. | 14:38.37 |
| | 1 hour | 14:38.47 |
| kens | thanks henrsy, time for a coffee then. I was concerned we had started | 14:39.03 |
| paulgardiner | tor8: yeah looks good | 14:40.46 |
| henrys | paulgardiner: or foods where fat in grams == 1/2 carbs grams | 14:40.48 |
| kens | looks like Miranda works for tor | 14:41.00 |
| tor5 | kens: it worked, but it took a real long while to join #ghostscript | 14:41.09 |
| | kens: any hints in the Miranda server window thing? | 14:41.26 |
| kens | Maybe I'm just not waiting long enough, I'll try again | 14:41.35 |
| | Well... Now it works. I'm really confused. | 14:42.25 |
| henrys | do we have any understanding of the ddos? | 14:42.47 |
| paulgardiner | henrys: strange though that it wasn't actually bad for you other than you were likely to eat too much of it. No carb diets or all carb diets were the things that were actually harmful. | 14:42.49 |
| kens2 | Lets see if it still works after I close Chatzilla | 14:42.54 |
| kens | Weird, its OK now. | 14:44.01 |
| henrys | paulgardiner: I thought that end of it was rather extreme - a month without a piece of fruit or a vegetable - he's lucky not to have scurvy or something | 14:44.04 |
| kens | Oh well, quick coffee time | 14:44.14 |
| Robin_Watts | sounds like "supersize me" | 14:48.08 |
| henrys | Robin_Watts: worse no bread - no fiber the guy can't poop and he's wondering why he can't think straight ⦠| 14:51.16 |
| | was there a security report posted somewhere about the irc failure? | 15:00.41 |
| Robin_Watts | henrys: not that I saw. There was a wallop earlier though. | 15:01.05 |
| henrys | I guess if that starts occurring a lot we can go to Skype until it's taken care of. | 15:02.01 |
| | Robin_Watts: you mean after the outage of 24 hours ago? | 15:05.46 |
| Robin_Watts | yeah. | 15:06.01 |
| ray_laptop | I couldn't get on using irc.ghostscript.com, but when I switched to freenode yesterday, it worked fine. Today irc.ghostscript.com works for me again (all with Chatzilla) | 15:16.37 |
| henrys | irc should be considered sacrosanct - what kind of idiot attacks irc? | 15:19.34 |
| | it sounds like mvrhel_laptop has gs hooked into the viewer for distilling! | 15:29.48 |
| | mvrhel_laptop: a last step should probably be to check gsview and see if there are any features a user would miss switching to the new product. | 15:30.42 |
| | Does anyone have any feeling about naming those products (gsview and gsprint)? I have mixed feeling about using the old names. | 15:31.40 |
| kens | People might expect behaviour that is not present | 15:32.13 |
| chrisl | If we're not going to use the old names, why did we do the deal with Russell? | 15:32.35 |
| kens | I'm inclined to keep the names, but its marginal | 15:33.10 |
| ray_laptop | I think we should use the old names. If someone asks for a feature, then we can decide whether or not to do it | 15:33.14 |
| mvrhel_laptop | good morning | 15:33.14 |
| henrys | chrisl: I think we would have done the deal anyway because the idea is derivative and we have a long relationship with russell so I'm not worried about that. | 15:33.26 |
| ray_laptop | morning, mvrhel_laptop | 15:33.31 |
| mvrhel_laptop | henrys: yes, I have it here and have been looking over the features | 15:33.37 |
| | my plan is to add most of those plus some interesting color stuff | 15:33.48 |
| marcosw | morning | 15:33.51 |
| ray_laptop | mvrhel_laptop: interesting to who ? ;-) | 15:34.09 |
| henrys | kens:but will the new gsprint have everything russell had? | 15:34.12 |
| mvrhel_laptop | color geeks of course | 15:34.17 |
| ray_laptop | mvrhel_laptop: I'll make sure and let Michael Chang know (at cust 532) | 15:34.42 |
| kens | henrys at the moment, no, in future, probably more | 15:34.45 |
| henrys | mvrhel_laptop: so gs uses the api - it isn't a "popen" of gs? | 15:35.25 |
| mvrhel_laptop | thanks ray_laptop . I will let the other two people who might use it also know ;) | 15:35.35 |
| | henrys: I am using the api | 15:35.57 |
| henrys | mvrhel_laptop, ray_laptop I think it will get some traction - sumatra has a niche, why wouldn't this be used? | 15:36.45 |
| mvrhel_laptop | henrys: I am thinking we are going to be competing with sumatra. this is going to be more of a viewer than gsview is | 15:37.27 |
| | or was | 15:37.30 |
| henrys | kens:and we have pretty much determined port monitoring is not interesting? | 15:37.57 |
| mvrhel_laptop | I have been looking over other viewers carefully to see what I want to add. doing the ui in wpf/xaml/c# makes things very easy to put together | 15:38.19 |
| ray_laptop | mvrhel_laptop: your gsview uses gs, right ? | 15:38.36 |
| henrys | mvrhel_laptop: yes that was one of my concerns but it's not clear it will be a zero sum game. | 15:38.37 |
| kens | henrys I do not believe port monitoring for Windows 8 at least is useful | 15:38.44 |
| mvrhel_laptop | ray_laptop: yes. and mupdf | 15:38.48 |
| ray_laptop | or is it mupdf based ? | 15:38.48 |
| kens | or indeed possible | 15:38.49 |
| ray_laptop | mvrhel_laptop: I see. _and_ not _or_ | 15:39.05 |
| mvrhel_laptop | ray_laptop: right | 15:39.13 |
| | ray_laptop: gs is being used as a distiller and also for creating stuff that mupdf cant | 15:39.38 |
| ray_laptop | mvrhel_laptop: so is gs's only role converting to pdf ? | 15:39.54 |
| | mvrhel_laptop: sorry I typed to slowly | 15:40.07 |
| mvrhel_laptop | or eps, or ps, or even out to other devices | 15:40.20 |
| | also for xpswrite | 15:40.22 |
| | which we will use for the print flow | 15:40.31 |
| ray_laptop | mvrhel_laptop: right. Makes sense | 15:40.35 |
| mvrhel_laptop | the API for mupdf is so much better for a viewer plus I am sharing my interface to mupdf that I wrote for windows 8 | 15:41.12 |
| | so right now the gsview project is actually in my winRT solution | 15:41.29 |
| ray_laptop | mvrhel_laptop: is your gsview on a git repo somewhere accessible ? | 15:41.32 |
| mvrhel_laptop | ray_laptop: I need to push it up | 15:41.46 |
| | I will get that done this week | 15:41.53 |
| | now that I have something that is starting to look reasonable | 15:42.08 |
| henrys | paulgardiner, Robin_Watts: of GhostDoc bugs - it does seem a lot of this is line spacing. I assume that is coming from the font, the question is are our fonts different or is the derivation from font metrics to line spacing wrong? | 15:42.10 |
| ray_laptop | mvrhel_laptop: I hope you have ti backed up somewhere :-) | 15:42.18 |
| paulgardiner | henrys: would require some investigation | 15:43.11 |
| henrys | that was really all I had on my list to talk about does anybody have anything else? | 15:43.27 |
| kens | henrys, chrisl added the xpsprint skeleton to GS if you want to play with it | 15:44.02 |
| Robin_Watts | henrys: I spoke to my contacts about this this morning again. | 15:44.22 |
| henrys | paulgardiner: I assume the fonts are buried somewhere in the epage directory? | 15:44.24 |
| paulgardiner | henrys: you sort of gave me the go ahead for an iOS release last week, but I'm wondering whether, being fairly close to a MuPDF release, I should hold off? | 15:44.24 |
| ray_laptop | it seems that having a database of line spacings for bunches of fonts would solve that even if our fonts differed. May need glyph metrics also if it the difference is due to line breaks from the reflow | 15:44.30 |
| marcosw | henrys: I just wanted to mention again that there is now a prviate ghostdocs area on bugs.ghostscript.com | 15:44.33 |
| Robin_Watts | They think that the fonts are exact clones of 1) the base 14 PDF fonts, and 2) the windows fonts. | 15:44.49 |
| | But I mentioned to them the idea of me trying to bundle the standard windows fonts into the exe to see if that would solve some of the layout issues, and they didn't think it was a stupid idea. | 15:45.37 |
| henrys | kens, chrisl yes I will look at that. Thanks | 15:45.40 |
| Robin_Watts | So I might try that. | 15:45.41 |
| paulgardiner | henrys: a not so good possibilty is that GhostDocs layout module is working in integer pixels. | 15:45.43 |
| mvrhel_laptop | I need to find some good files to have us open when we are in Japan | 15:45.52 |
| henrys | Robin_Watts: what is the source of these fonts? | 15:46.00 |
| kens | henrys you will have to build and run in at least WIndows Vista | 15:46.11 |
| paulgardiner | ... although I'd expect that to give errors not always in the same direction | 15:46.12 |
| henrys | kens:I have 8 | 15:46.23 |
| Robin_Watts | henrys: The fonts are in epage.git/libraries/font/library/ | 15:46.24 |
| | and they were licensed in from the Electronic Font Foundry. | 15:46.35 |
| chrisl | henrys: and you need the Windows SDK version 7 or better (for xpsprint) | 15:46.57 |
| ray_laptop | Robin_Watts: rather than bundle in the standard windows fonts, why not just use the ones in the windows fonts folder ? | 15:47.03 |
| Robin_Watts | (a guy called Eduard Poor, if memory serves. Did RISC OS fonts etc) | 15:47.07 |
| ray_laptop | that's what office is doing | 15:47.14 |
| Robin_Watts | ray_laptop: Yeah, but marcos is running the tests on linux, I think :) | 15:47.36 |
| marcosw | Robin_Watts: if you'd compile a da_test in non debug mode I could run the windows version... | 15:48.02 |
| Robin_Watts | and it might be easier to bundle than to try to massage the code into looking in windows? | 15:48.06 |
| chrisl | Ubuntu has a msttcorefonts (or similar name) package | 15:48.06 |
| henrys | paulgardiner: did the windows build every work or was that going to be a lot of work? | 15:48.24 |
| Robin_Watts | marcosw: I tried a release build. The FBS was still doing a debug link at the end. | 15:48.26 |
| marcosw | Robin_Watts: right. | 15:48.38 |
| Robin_Watts | I don't really want to have to fight the FBS more than I have to. | 15:48.44 |
| henrys | Robin_Watts: so if your source says they are the same can you simply ask him why a simple page of text does not match line advance wise? | 15:49.15 |
| | I do wish we have an anomaly document. | 15:49.33 |
| paulgardiner | henrys: bah! sorry somehow I completely forgot about that. I'll have a quick look later | 15:49.36 |
| henrys | s/have/had | 15:49.40 |
| Robin_Watts | They can't give a definitive answer. | 15:49.41 |
| henrys | paulgardiner: thanks | 15:49.54 |
| Robin_Watts | henrys: The windows build works. It just doesn't work on marcosw's machine. | 15:50.20 |
| paulgardiner | henrys: you mean the windows display app, right? Damn. I must write these things down. | 15:50.21 |
| Robin_Watts | oh, the viewer, right. | 15:50.38 |
| paulgardiner | Robin_Watts: I think we were talking about the viewer | 15:50.50 |
| marcosw | Robin_Watts: the .doc and .docx files are on casper, you can run the files and send me the bitmaps. | 15:51.07 |
| henrys | marcosw: is it possible to GhostDocs pdf output also, so we quickly see what is different from just pdf generation? Maybe that was done and I missed it? | 15:53.15 |
| | mvrhel_laptop: is going to need to have civil pdf output for Japan. | 15:54.03 |
| Robin_Watts | AIUI what was currently done was the Ghostdocs output bitmaps, and marcosw made pdfs of comparisons from that. | 15:54.32 |
| | No comparison has been done of ghostdocs pdf output vs ghostdocs bitmap output. | 15:54.58 |
| marcosw | henrys: Robin_Watts is correct, GhostDocs -> bmp | 15:54.58 |
| | ghostdocs pdf output vs ghostdocs bitmap would be easy to do. | 15:55.23 |
| | presumably it won't suffer from line break differences :-) | 15:55.40 |
| henrys | marcosw: the pdf output is probably of more immediate import at least for mvrhel_laptop's trip | 15:56.03 |
| Robin_Watts | I suspect it will differ in things like lack of underlining. | 15:56.15 |
| | and that is potentially something we can solve quickly. | 15:56.23 |
| henrys | anyway somebody should take on the immediate task of finding mvrhel_laptop a good set of files so he feels comfortable doing the demo. marcosw have you found any that are reasonably close? | 15:57.38 |
| marcosw | a lot of the simple ones are, but if you mean a complex one, no. otoh, i haven't looked at all of them. I'll do that right after the meeting. | 15:58.21 |
| henrys | marcosw: it seems like you are best positioned to feed mvrhel_laptop files as you find them. | 15:58.56 |
| | ray_laptop: you you got the banding for non printing devices in, very cool! | 15:59.22 |
| kens | Yes, that's a huge improvement | 16:00.03 |
| | And I'm very happy it wasn't me that had to do it! | 16:00.16 |
| henrys | it is 9 so let's adjourn but I'll be here most of the day. | 16:00.47 |
| ray_laptop | henrys: I have some bug tail I am investigating, but yes, it works reasonably well. It sure is a performance hit, however (compared to page mode). | 16:00.48 |
| henrys | ray_laptop: sure it's a tradeoff | 16:01.10 |
| kens | ray yes, I'm sure that's true, but for files which don;t work otherwise its a huge boost | 16:01.44 |
| ray_laptop | henrys: right. And at least MaxBitmap allows a user to stick with page mode. | 16:01.47 |
| | kens: yeah. It was really nice to close the oldest customer bug :-) | 16:02.14 |
| kens | :-) | 16:02.22 |
| ray_laptop | I'm down to one customer bug and that one is not really from the customer, so they aren't waiting for it | 16:03.44 |
| henrys | marcosw: i wonder if the line advance is such an overarching issue we shouldn't fix that first before we do more testing. Every file I look at suffers from that. | 16:06.43 |
| | paulgardiner: you said this may be non trivial though? the layout machinery? | 16:07.31 |
| Robin_Watts | henrys: I really doubt that will be a simple fix. | 16:08.11 |
| | (Unless it's a question of fonts having the wrong metrics) | 16:08.20 |
| | If it was trivial to fix, Picsel would have done so already. | 16:08.37 |
| henrys | paulgardiner: probably naive but would moving to greater precision fixed point work? | 16:08.46 |
| | Robin_Watts: yes good point | 16:09.11 |
| paulgardiner | henrys: that was only a wild guess concerning precision | 16:09.16 |
| | And now I come to thing of it layout should be working independently of resolution | 16:09.37 |
| tor8 | henrys: there's also the possibility of word's line breaking being dependent on the currently selected printer in the preferences | 16:09.38 |
| Robin_Watts | I think we should try a "quick fix" of changing the fonts it uses. | 16:10.05 |
| paulgardiner | It would be the rendering of the display list where integer pixel positions would be an issue, I think | 16:10.09 |
| Robin_Watts | If we change that and we get no differences, then we can be happy that the inbuilt fonts are a good match to windows ones. | 16:10.32 |
| marcosw | henrys: I think I agree. On my many files the issue seems not to be line breaks, but just spacing between lines. I'll enter a bug :-) | 16:10.47 |
| Robin_Watts | Then the "next lowest hanging fruit" is probably the stuff missing from pdf exports. | 16:11.09 |
| | Then someone needs to take the time to run through the entire layout process to watch what happens and try and see problems. | 16:11.39 |
| | but that's a potentially long and arduous problem. | 16:11.57 |
| | I'll take on trying to change the fonts (either by bundling the windows ones, or by making the font engine look for them) | 16:12.54 |
| henrys | tor8:oh you mean the selected printer in office? | 16:13.08 |
| tor8 | henrys: yeah. word pagination and word breaks depends (depended... in old versions at least) on the printer properties | 16:13.36 |
| Robin_Watts | tor8: Someone could try looking to see if that setting is read from the file and consulted during layout. | 16:13.49 |
| tor8 | like printer resolution, since it applies font hinting at the target printer resolution and uses those metrics | 16:14.00 |
| | and printable area might affect margins, etc, etc | 16:14.13 |
| henrys | tor8:this looks much bigger than I'd expect from hinting. | 16:14.28 |
| Robin_Watts | Hmm. I don't think the picsel font engine does hinting. | 16:14.44 |
| henrys | tor8: a couple lines a page | 16:14.45 |
| tor8 | henrys: well, where the word breaks land would depend on the accurate metrics, and once you get one break that's off that'll escalate | 16:15.24 |
| Robin_Watts | On another subject, last week we discussed the idea of calling torscript muscript or mujscript. | 16:16.21 |
| henrys | tor8:many of the files I looked at had line spacing problems only, there wasn't wraparound | 16:16.25 |
| mvrhel_laptop | marcosw: thank you for helping me | 16:16.26 |
| Robin_Watts | Ray then piped up later and suggested "mujs". That's my favourite one so far. | 16:16.41 |
| henrys | I like ray_laptop's best also. | 16:17.10 |
| tor8 | mujs, mujscript, or mujavascript would all be fine by me | 16:17.41 |
| Robin_Watts | OK. The Picsel font engine does not do hinting (just had that confirmed) | 16:18.18 |
| henrys | So I suppose somebody should get the ISO spec for MS Word - one obvious thing to do is see what the predicted value for line advance should be according to the specification and see what we actually get, that could be a clue where to look. | 16:18.40 |
| Robin_Watts | ISO spec? really? :) | 16:19.13 |
| tor8 | mujs has many more existing google hits. | 16:19.16 |
| ray_laptop | henrys: so you think MS office actually meets the spec ? I doubt anybody at MS even cares about specs | 16:19.40 |
| henrys | ray_laptop: I'm picturing something halfway between pcl and postscript | 16:20.15 |
| Robin_Watts | Certainly the pre OOXML versions of office had no iso spec. | 16:20.27 |
| | There were file specs you could buy from ms, but they were hard to get. | 16:20.40 |
| henrys | well now there is an iso spec, I saw it yesterday don't remember the number. | 16:21.30 |
| Robin_Watts | There is an ISO spec for the OOXML stuff I think. | 16:22.27 |
| | but I wouldn't like to predict exactly how closely word actually follows it. | 16:22.44 |
| henrys | Robin_Watts: yes it doesn't cover the old stuff | 16:22.49 |
| Robin_Watts | I guess the OOXML stuff is most important. | 16:24.30 |
| marcosw | I found a 'simple' .doc file that exhbits line spacing problems (but not word) wrap and have entered a bug. Is Robin_Watts the lukcy assignee? | 16:24.51 |
| henrys | it's also going to be the horrid prose like xps or the "new" pdf spec. | 16:24.59 |
| Robin_Watts | marcosw: Sure. | 16:25.19 |
| | The only "mujs javascript" hit that seems meaningful is: https://github.com/pwseo/mujs | 16:25.57 |
| | and that's 3 years old, and consists of a single commit of a single file. | 16:26.11 |
| henrys | off to shovel again, I wish some of our weather would head down toward's ray_laptop | 16:27.02 |
| ray_laptop | me too! | 16:29.11 |
| | Robin_Watts: right. With no log message or anything to indicate what the heck it is (AFAICT) | 16:32.14 |
| Robin_Watts | ray_laptop: indeed. | 16:32.39 |
| ray_laptop | tor8: BTW, how does your implementation (whatever it's called) compare with tiny-js ? | 16:34.57 |
| tor8 | ray_laptop: mujs supports the full language spec | 16:37.11 |
| | tiny-js is a toy | 16:37.31 |
| ray_laptop | tor8: Great! So once we have a name for yours, we can post something to make the tiny-js users happy that there is something better available | 16:40.57 |
| | mvrhel_laptop: Robin_Watts: I am looking into bug 694821 and I have found something in the psdcmyk device that makes it work, but doesn't seem quite right. | 16:48.23 |
| | pdf_prn_open line 398 sets color_info.num_components to pdev_psd->max_spots + 4, even though the 'open' call is because the device was closed by a put_params that set the num_components to 1. | 16:48.24 |
| | It was set to 1 because there was a SeparationOrder [ /Black ] in the file. | 16:48.26 |
| Robin_Watts | That doesn't sound ideal. | 16:55.15 |
| | marcosw: Does the version of windows-da-test.exe in my home dir run on your machine? | 16:55.32 |
| ray_laptop | The psdcmykog device doesn't do this, so it ends up with num_components == 1 | 16:55.51 |
| Robin_Watts | I think I've changed the final link to avoid the /DEBUG switch. | 16:56.09 |
| | ray_laptop: and which is working? psdcmykog or psdcmyk ? :) | 16:56.33 |
| ray_laptop | and a planar device that only has 1 component doesn't set the fill_rectangle_hl_color proc | 16:56.40 |
| | psdcmyk works. psdcmykog fails (thus the bug) | 16:56.59 |
| Robin_Watts | right. | 16:57.05 |
| | But is psdcmykog actually wrong about the number of components? | 16:57.41 |
| ray_laptop | now I can "fix" the bug by doing what psdcmyk does, but I'd like to know which seems right. | 16:57.47 |
| Robin_Watts | Or is it getting the number of components right because it's exposing a bug elsewhere? | 16:58.01 |
| ray_laptop | it does mean that when the psdcmyk is told to only render Black, it is still keeping 14 planes | 16:58.24 |
| Robin_Watts | Possibly all single component devices should have the fill_rectangle_hl_color procs filled in. | 16:58.34 |
| mvrhel_laptop | henrys: you there? | 16:59.37 |
| henrys | mvrhel_laptop: yes, I'm back | 16:59.48 |
| mvrhel_laptop | so I was hooking up the xps print stuff into gsview. | 16:59.54 |
| | I can't even get xpswrite to do tiger.eps from the command line | 17:00.10 |
| | it crashes | 17:00.13 |
| | in zip_look_up_file_info | 17:00.26 |
| henrys | I thought you were going to gloat about the seahawks | 17:00.30 |
| mvrhel_laptop | hehe | 17:00.34 |
| | that was quite a game | 17:00.40 |
| henrys | I have an explanation - you haven't opened retail marijuana shops yet. | 17:01.00 |
| mvrhel_laptop | yes. the broncos looked a little dazed | 17:01.13 |
| henrys | mvrhel_laptop: I haven't looked at it recently but it is fairly simple send me a file | 17:01.56 |
| kens | mvrhel_laptop : is that to me about tiger ? | 17:02.11 |
| henrys | tiger.eps you say | 17:02.21 |
| mvrhel_laptop | yes | 17:02.23 |
| kens | because that one definitely works for me here | 17:02.28 |
| mvrhel_laptop | the one in our examples | 17:02.30 |
| henrys | I was testing with that all along, strange | 17:02.30 |
| mvrhel_laptop | weird | 17:02.36 |
| kens | mvrhel_laptop : is this with regular GS ? | 17:02.44 |
| mvrhel_laptop | yes | 17:02.47 |
| kens | from teh command line ? | 17:02.48 |
| mvrhel_laptop | yes | 17:02.50 |
| chrisl | 32/64 bit? | 17:02.59 |
| kens | Hmm well I didn't try it sionce chris hooked up the xpsprintcode | 17:03.05 |
| | Let me update and try | 17:03.11 |
| mvrhel_laptop | gswin64c -sDEVICE=xpswrite -sOutputFile="test.xps" -f ..\examples\tiger.eps | 17:04.12 |
| kens | Oh I was trying 32-bit | 17:04.28 |
| mvrhel_laptop | I have not updated in a bit though | 17:04.29 |
| kens | Will need to rebuild | 17:04.32 |
| mvrhel_laptop | oh. you are working in the stone age | 17:04.36 |
| | i see | 17:04.39 |
| kens | I flip back and forth | 17:05.06 |
| henrys | mvrhel_laptop: I was working on 64 bit mac and linux to do xpswrite but I never tried windows | 17:05.14 |
| | 64 | 17:05.16 |
| kens | depends if a bug needs 32 bit or not | 17:05.19 |
| mvrhel_laptop | let me try 32 bit | 17:05.25 |
| kens | rebuilding 54-bit right now | 17:05.31 |
| | err 64 | 17:05.34 |
| | 32-bit definitely works with the currne code for me | 17:05.52 |
| | gswin32c -sDEVICE=xpswrite -sOutputFile=\temp\out.xps \ghostpdl\gs\examples\tiger.eps | 17:06.23 |
| chrisl | Works for me..... | 17:07.14 |
| | It does give a warning about "xps_rect: type not supported 4" | 17:07.47 |
| kens | yes I see that too | 17:07.59 |
| henrys | chrisl: that's expected | 17:08.03 |
| kens | In 32-bit | 17:08.05 |
| mvrhel_laptop | well let me make sure I am all updated too | 17:08.32 |
| chrisl | This was 64 bit | 17:08.34 |
| kens | I see MS has a new CEO | 17:08.39 |
| chrisl | Already? I thought it was expected to take a while | 17:09.14 |
| kens | 64-bits works for me too | 17:09.29 |
| mvrhel_laptop | wtf | 17:09.32 |
| kens | http://www.theregister.co.uk/2014/02/04/satya_nadella_new_microsoft_ceo/ | 17:09.39 |
| | Bill no longer chariman either | 17:09.47 |
| mvrhel_laptop | let me clean and rebuild etc | 17:09.55 |
| henrys | kens: can you try with -Z@ also | 17:10.08 |
| | ? | 17:10.12 |
| kens | OK | 17:10.13 |
| chrisl | -Z@ needs a debug build, doesn't it? | 17:10.35 |
| kens | works fine no additional warnings | 17:10.41 |
| henrys | chrisl: yes | 17:10.48 |
| kens | It is a debug build | 17:10.50 |
| chrisl | Mine was a release bulid | 17:10.58 |
| | or build, even | 17:11.06 |
| kens | both mine are debug | 17:11.11 |
| | 32 & 64 | 17:11.15 |
| henrys | mvrhel_laptop: are you on a production build? | 17:11.30 |
| mvrhel_laptop | I was running a debug build | 17:11.51 |
| | hold on doing a update/clean/rebuild | 17:12.01 |
| kens | well my 64-bit build was a full clean and rebuild, it was a bit out of date | 17:12.16 |
| | I'll do all 4 | 17:12.24 |
| | It'll take a few minutes | 17:12.29 |
| henrys | could it be studio versions? | 17:14.35 |
| | hopefully it will go away with mvrhel_laptop's rebuild | 17:15.02 |
| mvrhel_laptop | ok that fixed it. sorry to drag you all into that | 17:16.28 |
| | henrys, kens, chrisl ^^ | 17:16.42 |
| kens | No problem, glad its OK now, had me worried :-) | 17:16.53 |
| henrys | that's a relief | 17:17.01 |
| kens | OK goodnight folks | 17:21.01 |
| mvrhel_laptop | blah. I actually am still having the issue with the 64 bit debug build. let me see if I can figure this out | 17:32.23 |
| | 32 bit is working ine | 17:32.29 |
| | fine | 17:32.30 |
| | hmm let me go to VS 2012... | 17:38.37 |
| | dang same thing | 17:47.29 |
| Robin_Watts | tor5, tor8: ping | 17:48.21 |
| | mvrhel_laptop: Want me to see if I get the same problem here? | 17:56.12 |
| henrys | same crash in zip_look_up_file_info, can you paste a backtrace somewhere? | 17:57.44 |
| chrisl | mvrhel_laptop: you're not streaming the output from xpswrite (e.g. through a pipe)? | 17:57.59 |
| mvrhel_laptop | chrisl. no | 17:58.13 |
| | but something is messed up. I can't even build the 64 bit release for some reason with VS2012 or VS2013 | 17:58.36 |
| henrys | chrisl: yeah he just had a regular command line | 17:58.38 |
| mvrhel_laptop | the 32 bit version runs fine | 17:58.53 |
| | the 64 bit debug version gives me the crash | 17:59.05 |
| | and I cant build the 64 bit release | 17:59.12 |
| henrys | mvrhel_laptop: compiler error | 17:59.36 |
| | ? | 17:59.37 |
| mvrhel_laptop | hold on let me figure out the build issue | 17:59.38 |
| | 1> /NODEFAULTLIB:LIBCMTD.lib | 18:00.38 |
| | 1> LIBCMT.lib | 18:00.39 |
| | 1> shell32.lib | 18:00.41 |
| | 1> comdlg32.lib | 18:00.43 |
| | 1> gdi32.lib | 18:00.44 |
| | 1> user32.lib | 18:00.46 |
| | 1> winspool.lib | 18:00.47 |
| | 1> advapi32.lib | 18:00.49 |
| | 1> ws2_32.lib | 18:00.50 |
| | 1> ole32.lib | 18:00.52 |
| | 1>LINK : fatal error LNK1104: cannot open file '.\bin\gsdll64.dll' | 18:00.53 |
| | 1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64\link.EXE"' : return code '0x450' | 18:00.55 |
| | 1> Stop. | 18:00.56 |
| | 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "nmake -f psi\msvc32.mak WIN64= SBR=1 DEVSTUDIO= && nmake -f psi\msvc32.mak WIN64= DEVSTUDIO= bsc" exited with code 2. | 18:00.58 |
| | ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== | 18:00.59 |
| | this seems like it would be something I did, but I do have a clean check out | 18:01.08 |
| chrisl | Does gsdll64.dll exist? | 18:01.34 |
| mvrhel_laptop | oh crap | 18:02.02 |
| Robin_Watts | mvrhel_laptop: That smells to me as if something has died in your system while holding a handle to gsdll64.bll | 18:02.03 |
| mvrhel_laptop | I see | 18:02.04 |
| | the old version of gsview has it open | 18:02.11 |
| | sheesh | 18:02.15 |
| Robin_Watts | FWIW, the 64bit debug build works fine under VS2005. | 18:02.39 |
| mvrhel_laptop | ok. now I am building release version | 18:02.48 |
| | let me see if that has the crash | 18:02.54 |
| henrys | no so shared libraries | 18:03.02 |
| | s/no/not | 18:03.07 |
| mvrhel_laptop | ok. so I get the same darn issue release and debug | 18:04.52 |
| | I guess since I am the only one, I get to figure out what is the problem | 18:05.21 |
| | let me see if I have VS2005 on this thing first | 18:05.39 |
| | nope. ok | 18:06.18 |
| | I have to run my car to the shop. will beat on this a bit later | 18:06.32 |
| henrys | Robin_Watts: does xpswrite tiger for you? | 18:07.26 |
| Robin_Watts | It does. | 18:07.45 |
| chrisl | I'm building with VS2012 now - but I'm short on time.... | 18:10.41 |
| mvrhel_laptop | henrys: since the 32 bit version works for me, I can look at the stack and figure out where/when things go different for me | 18:11.05 |
| henrys | mvrhel_laptop: okay sorry you tripped over this. | 18:12.20 |
| Robin_Watts | mvrhel_laptop: What version are you using other than 2012? | 18:12.27 |
| | I don't have 2012 locally. | 18:12.38 |
| | I have 2008 and 2010 express. | 18:12.44 |
| | as well as 2005. | 18:12.49 |
| mvrhel_laptop | Robin_Watts: I have 2012 and 2013 | 18:13.24 |
| Robin_Watts | ok, so I'll try to rebuild with 2010, but if I cannot reproduce the problem here that won't tell us much. | 18:13.59 |
| mvrhel_laptop | here is the back trace | 18:17.31 |
| | > gsdll64.dll!strcmp() Line 105 | 18:17.39 |
| | > gsdll64.dll!zip_look_up_file_info(gx_device_xps_s * xps_dev, const char * filename) Line 359 | 18:17.40 |
| | > gsdll64.dll!write_to_zip_file(gx_device_xps_s * xps_dev, const char * filename, unsigned char * data, unsigned int len) Line 420 | 18:17.42 |
| | > gsdll64.dll!write_str_to_zip_file(gx_device_xps_s * xps_dev, const char * filename, const char * str) Line 479 | 18:17.43 |
| | > gsdll64.dll!xps_open_device(gx_device_s * dev) Line 656C | 18:17.45 |
| | >gsdll64.dll!gs_opendevice(gx_device_s * dev) Line 393C | 18:17.46 |
| Robin_Watts | Ok, I can't import into VS2010 Express for some reason. | 18:18.30 |
| | Let me finally get around to installing VS2010 and try. | 18:18.39 |
| | mvrhel_laptop: Can you examine the values being passed to strcmp ? | 18:18.54 |
| mvrhel_laptop | yes. cur->filename is bogus | 18:19.30 |
| chrisl | So, my VS2012 build works for me | 18:19.56 |
| mvrhel_laptop | filename is ok . It is FixedDocumentSequence.fdseq | 18:19.56 |
| | really? | 18:20.03 |
| | I am not doing anything special here | 18:20.41 |
| chrisl | I can't vouch for the output, but I get a nice test.xps file out, and no seg fault | 18:20.45 |
| henrys | mvrhel_laptop: can you print xps_dev->f2i the head of the list | 18:21.22 |
| | ? | 18:21.25 |
| chrisl | Actually, the output is fine, too | 18:21.30 |
| | mvrhel_laptop: are you using the "METRO" build? | 18:22.07 |
| mvrhel_laptop | chrisl: I am just building it as is | 18:22.31 |
| | is there some special define I need? | 18:22.45 |
| henrys | mvrhel_laptop: if you do -Z_ it will check that list periodically and see when it was broken | 18:22.58 |
| | mvrhel_laptop: with a debug build | 18:23.06 |
| chrisl | Well, I'm building at the command line, but not doing anything special | 18:23.20 |
| mvrhel_laptop | henrys: f2i seems to be bogus | 18:23.46 |
| | let me run with -Z_ | 18:23.57 |
| henrys | mvrhel_laptop: then nothing will work right | 18:24.19 |
| chrisl | mvrhel_laptop: have you tried other devices? | 18:24.54 |
| mvrhel_laptop | good idea... | 18:25.25 |
| | pdfwrite worked fine | 18:25.37 |
| henrys | I do seem a strdup slipped in but I don't think that would be it. | 18:25.39 |
| | s/seem/see | 18:26.03 |
| mvrhel_laptop | and I have a nice tiger just changing xpswrite to pdfwrite | 18:26.48 |
| | so at least something works.... | 18:27.30 |
| henrys | mvrhel_laptop: if you can email me the -Z_ I'll study it. | 18:27.33 |
| mvrhel_laptop | henrys: ok. I don't want to chew up everyones time on this. | 18:27.49 |
| chrisl | mvrhel_laptop: I have to head off - if you don't get anywhere, leave a message on here. Tomorrow, I can fire up Win8 and build with VS2012 in that, and try it out. | 18:27.50 |
| henrys | mvrhel_laptop: it's new code I anticipate problems | 18:28.17 |
| mvrhel_laptop | let me dig a bit more since I have a win32 working I can compare easily where things go different | 18:28.19 |
| chrisl | Okay, bye! | 18:28.43 |
| mvrhel_laptop | I will see where xps_dev->f2i goes wrong | 18:28.48 |
| | I need to get my car in | 18:28.53 |
| | or else lose me spot | 18:28.57 |
| | bbiaw | 18:28.58 |
| Robin_Watts | tor5, tor8: ping | 18:53.09 |
| tor5 | Robin_Watts: pong. | 18:57.54 |
| Robin_Watts | tor8: (For the logs) I've got updated versions of those commits on robin/master for your perusal. | 18:58.01 |
| | aha. | 18:58.03 |
| | It seems that the change to the array parsing has triggered 2 things. | 18:58.22 |
| | One file is getting a dotted line right that it was previously getting wrong. | 18:58.36 |
| | So I can only assume it was doing a [] 0 d thing in a BT...ET before, and hence we were getting it wrong. | 18:59.04 |
| | And another file is doing [ (foo) 0.0 Tc (bar) 0.0 Tc (baz) ] TJ | 18:59.40 |
| | The final commit on there works around that. | 18:59.58 |
| tor5 | Robin_Watts: yeah. that second file is just broken in so many ways... | 19:00.09 |
| Robin_Watts | I'm open to suggestions for improval of any of this stuff. | 19:00.28 |
| | or improvement even. | 19:01.07 |
| tor5 | Robin_Watts: question is, why not always be lax when parsing arrays? | 19:01.56 |
| Robin_Watts | cos we run the risk of going into an infinite loop | 19:02.17 |
| tor5 | though I have this nagging suspicion we're just exacerbating the problem of broken pdf files by accepting them... | 19:02.31 |
| Robin_Watts | And the way I've coded the laxness, we know that we will always report the error at least. | 19:02.42 |
| | Imagine the case where a file loses the ]. | 19:03.01 |
| tor5 | then we'll read till EOF | 19:03.15 |
| Robin_Watts | If we are always lax, then we'll parse the entire file... yeah. | 19:03.22 |
| | Now, that's exactly what we'd have done in the old version of this code (well, End Of Stream at least) | 19:03.47 |
| | so I don't feel bad about that. | 19:03.51 |
| | I'm happier to lose the rest of a stream than I am to lose an entire file. | 19:04.15 |
| tor5 | Robin_Watts: in case of mismatched BT/ET TJ arrays, we wouldn't be affected by that at all though, and it seems like there is where most abuse of arrays happens | 19:04.39 |
| | which I think is also part of what prompted me to do the previous approach, more than the memory savings | 19:04.58 |
| | Robin_Watts: right. | 19:05.16 |
| Robin_Watts | I did ponder on a more complex heuristic, whereby we'd accept a certain number of broken entries in a row before giving up. | 19:05.18 |
| | but I figured that this was the minimal change to get us something no more broken than the old code was. | 19:05.49 |
| tor5 | Robin_Watts: I forgot the reason why you want to change how we parse TJ arrays in the first place... | 19:05.54 |
| Robin_Watts | but I'm open to other arguments. | 19:06.02 |
| | tor5: For filtering. | 19:06.15 |
| tor5 | it ought to be independent of the pdf_run_xx interfacing | 19:06.17 |
| | hm. well, it just means we won't emit TJ arrays ourselves right? just a sequence of primitive Txxx calls. | 19:07.01 |
| Robin_Watts | Or we'd emit lots of singleton arrays then TJ. | 19:07.36 |
| | But I want to be able to keep operator streams as intact as possible. | 19:07.58 |
| tor5 | Robin_Watts: right. so we could have a special array parsing mode like in the previous approach, but instead of calling show/move for each element, we append them to an array. there's no need for recursive array parsing here. | 19:09.08 |
| | and it would leave the original array parsing alone | 19:09.16 |
| tor8 | Robin_Watts: I'll be back in a few hours. | 19:13.56 |
| Robin_Watts | tor8: Will ponder that. | 19:16.32 |
| | VS2010 build works for me too. | 19:36.19 |
| | I wonder if it's something specific to Windows 8 here? Possibly in the way that the zipfile is opened (or maybe fails to open) | 19:36.51 |
| henrys | Robin_Watts: when are you going to upgrade? 8.2? | 19:58.05 |
| Robin_Watts | henrys: Never, if I can possibly avoid it. | 20:03.13 |
| | I managed to avoid Vista entirely by hanging on with XP. | 20:03.33 |
| | Microsoft seem to get every other release right, so maybe 9 will be OK :) | 20:04.04 |
| mvrhel_laptop | ok I am back | 20:52.43 |
| | let me step through this thing and see where xps_dev->f2i goes wrong | 20:53.26 |
| | henrys: so this f2i->filename = strdup(filename); is the culprit | 21:04.03 |
| | not sure why though yet | 21:04.53 |
| Robin_Watts | strdup is considered unsafe. | 21:05.25 |
| mvrhel_laptop | it is weird | 21:06.41 |
| Robin_Watts | mvrhel_laptop: If you replace the strdup with an explicit strlen/malloc/strcpy, does the problem go away? | 21:06.47 |
| mvrhel_laptop | it has done an allocation in a place I can see | 21:06.49 |
| | ok | 21:06.55 |
| | s/can/can't | 21:07.00 |
| | Robin_Watts: let me do what you suggest | 21:07.09 |
| Robin_Watts | all: I've just put a new link on the regression dashboard, to the 'epage-docs' directory. | 21:07.52 |
| ray_laptop | Robin_Watts: thanks. I guess :=/ | 21:08.25 |
| Robin_Watts | If someone could try it and confirm that it works for them, I'd be grateful. | 21:09.52 |
| | well, it'll be useful for me if no one else :) | 21:10.06 |
| mvrhel_laptop | Robin_Watts: works for me | 21:10.20 |
| Robin_Watts | ta. | 21:10.26 |
| mvrhel_laptop | Robin_Watts: that fixed the issue | 21:16.19 |
| | so why was this happening to me and no one else. | 21:16.51 |
| ray_laptop | probably since it is unsafe, MS was helping you by making the function a no-op ? | 21:17.22 |
| | there's probably a warning buried in the output somewhere | 21:17.44 |
| mvrhel_laptop | no | 21:17.52 |
| ray_laptop | mvrhel_laptop: can you trace into strdup with the debugger ? | 21:18.11 |
| mvrhel_laptop | I stepped into the code for strdup | 21:18.13 |
| | yes | 21:18.15 |
| | it is doing an allocation but it appears to be in a bad place | 21:18.29 |
| | like I said, I can't view that location with the debugger | 21:18.48 |
| | that is the memory location that it returns | 21:18.56 |
| | and the rest of the code does not like it obviously | 21:19.16 |
| | I suggest that strdup is bad to use since we are not doing the allocation ourselves | 21:19.41 |
| ray_laptop | so it's like "I did the strdup, but I'm not going to tell you what the result is" | 21:19.50 |
| | na-na | 21:20.02 |
| mvrhel_laptop | here is the malloc that it did | 21:20.21 |
| | if (memory = _malloc_dbg(size, nBlockUse, szFileName, nLine)) | 21:20.23 |
| | in the non-debug case, which also fails it is doing a malloc | 21:22.06 |
| | so, in any case, it would be best if we avoid the use of strdup | 21:22.47 |
| | now let me see if I can find out where I need to free f2i->filename | 21:23.53 |
| | anyone want to guess where? I suppose each time it adds a new file to the archive we need to free someplace | 21:25.40 |
| henrys | mvrhel_laptop: yes I said strdup is wrong | 21:28.14 |
| mvrhel_laptop | henrys: ok | 21:28.34 |
| henrys | it isn't freed at the moment. | 21:28.36 |
| mvrhel_laptop | oh. well it was the allocation that was crashing on me | 21:28.53 |
| henrys | but I can't imagine that matters | 21:28.53 |
| | weird | 21:29.01 |
| mvrhel_laptop | actually the allocation was handing back a bad memory address | 21:29.12 |
| | so I fixed that with a proper gs_alloc_bytes strcpy | 21:29.26 |
| | but I am trying to understand where I should free it | 21:29.50 |
| henrys | mvrhel_laptop: and it just works now? | 21:29.51 |
| mvrhel_laptop | henrys: yes | 21:29.55 |
| | where are *info and *f2i freed? | 21:30.27 |
| | oh I see you have a comment that they should be GCd | 21:30.58 |
| henrys | mvrhel_laptop: they aren't just yet. | 21:31.09 |
| mvrhel_laptop | ok. so if you are ok, I am going to push this little fix | 21:31.14 |
| henrys | mvrhel_laptop: that's why I find int odd | 21:31.18 |
| | mvrhel_laptop: sure fine | 21:31.31 |
| mvrhel_laptop | ok thanks | 21:31.38 |
| | Robin_Watts: thanks for the suggestion of the strlen/malloc/strcpy | 21:36.01 |
| | now let me see if my printing works.... | 21:36.16 |
| henrys | but why on earth would it work in a 32 bit environment. | 21:37.58 |
| | ? | 21:37.59 |
| mvrhel_laptop | henrys: I have no idea | 21:39.00 |
| | but memory allocations are a weird thing | 21:39.11 |
| | looks like I have a little work to do | 21:42.10 |
| | i have to head out again for a bit though | 21:42.17 |
| | bbs | 21:42.19 |
| | Forward 1 day (to 2014/02/05)>>> | |
IRC Logs