| | <<<Back 1 day (to 2013/07/28) | 2013/07/29 |
| paulgardiner | tor7: ping | 09:23.27 |
| tor7 | paulgardiner: mornin' | 09:23.39 |
| paulgardiner | Hi. Did you get a chance to look at the two commits on paul/master? | 09:23.59 |
| tor7 | paulgardiner: not yet. will look. | 09:24.16 |
| paulgardiner | ta | 09:24.21 |
| tor7 | paulgardiner: fontdescriptor /Name entry is deprecated since PDF 1.2 I believe | 09:26.55 |
| | just let me double check the spec | 09:27.04 |
| paulgardiner | Would make sense since it seems unnecessary. | 09:27.28 |
| tor7 | sorry, not font descriptor. Font dictionary /Name entry is optional since 1.1 | 09:28.59 |
| paulgardiner | I'm happy to remove it. What do you reckon? | 09:29.45 |
| tor7 | pdfref17 has a "Note: This entry is obsolescent and its unse is no longer recommended." | 09:30.43 |
| paulgardiner | Okay. I'll remove that. | 09:31.02 |
| tor7 | the "FIXME: it->ucs should be converted to the correct encoding" comment, shouldn't that read "it->gid" instead? | 09:32.09 |
| | size = trm.a won't work for 90 degree rotated text. use fz_matrix_expansion() to extract the scale factor. | 09:33.18 |
| paulgardiner | Oh excellent. I realised I should be working out the expansion but didn't know we had a function for it. | 09:35.41 |
| | Robin_Watts: Hi. Where are you? | 09:40.24 |
| tor7 | Robin_Watts: I thought you'd be far away from home by now...? | 09:40.40 |
| paulgardiner | tor7: Just those three things to change? | 09:42.08 |
| tor7 | paulgardiner: in the first patch, yes. the rest looks fine. | 09:42.23 |
| | paulgardiner: I'm not clear on what happens in pdf_set_free_text_annot_appearance() | 09:43.04 |
| paulgardiner | Those are in the second I thought | 09:43.07 |
| tor7 | just by looking at the header file | 09:43.14 |
| sebras | tor7: paulgardiner: Robins account seems to have been disconnected, so I think this is a simple reconnect. | 09:43.16 |
| tor7 | it says "set" in the name, but takes no arguments | 09:43.38 |
| paulgardiner | I've called similar functions "update" elsewhere possibly. | 09:44.10 |
| tor7 | sebras: so we're going to have ghost robin here for a few weeks then? ;) | 09:44.22 |
| paulgardiner | Would that be better | 09:44.25 |
| tor7 | paulgardiner: update would be better, yes | 09:44.40 |
| paulgardiner | okay | 09:44.51 |
| tor7 | the name would match the comment better then :) | 09:45.15 |
| | paulgardiner: FT_LOAD_NO_BITMAP | FT_LOAD_NO_HINTING | are impled by FT_LOAD_NO_SCALE so can be elided | 09:47.25 |
| | in layout_text() | 09:47.34 |
| paulgardiner | Okay. Handy | 09:47.53 |
| tor7 | fz_chartorune converts from utf8 to unicode (which is one step closer to WinAnsi than each byte of a utf-8 string separately) | 09:49.08 |
| | for the FIXME: convert str tfrom utf8 to WinAnsi | 09:49.18 |
| paulgardiner | was hoping to leave that and sort it out in one go | 09:50.11 |
| tor7 | that's fine | 09:50.16 |
| | just pointing out a function if you don't know it already :) | 09:50.40 |
| paulgardiner | Right. | 09:51.02 |
| tor7 | in pdf_set_free_text_annot_appearance you have a variable "dr" for holding the resource dictionary. what's the logic behind that name? | 09:51.31 |
| | elsewhere we've used "rdb" (which isn't a whole lot more logical) | 09:51.49 |
| | I assume get_font_info is an older function? | 09:52.23 |
| paulgardiner | Yes, it's from the earlier forms work | 09:53.01 |
| | Passing dr in would make that part work for other types of fonts | 09:53.42 |
| tor7 | so no line breaking in layout_text? | 09:53.48 |
| paulgardiner | Although the whole thing would fail further on | 09:53.56 |
| tor7 | ah, you use "dr" consistently in the forms code I take it? | 09:54.43 |
| paulgardiner | I believe so. | 09:55.04 |
| tor7 | in pdf_set_free_text_details you always create a new font? no attempt to reuse? | 09:55.59 |
| | and the same thing with the /Name entry of the font dictionary in there | 09:57.04 |
| paulgardiner | Intending to add that later. i.e., look for a already existing usable font | 09:57.37 |
| tor7 | alright. | 09:57.53 |
| | I'm thinking pdf_measure_text and layout_text ought to be very similar | 09:58.15 |
| paulgardiner | although, pdf_set_free_text_details creates the font in the xobject resources, and that is recommended to have its own copy | 09:58.34 |
| tor7 | do you mean that the xobject resources should have a unique copy of the font object? | 09:59.24 |
| | each xobject would have its own font then? that seems wasteful | 09:59.51 |
| paulgardiner | Well, it should have its own reference to it, I guess | 10:00.21 |
| tor7 | the /Resource dictionary should be unique, so the /F%d name would probably be unique to each xobject | 10:01.00 |
| paulgardiner | I think sorting out that requires passing tow resources to the pdf device. | 10:01.12 |
| tor7 | but I think we should share the actual Font and FontDescriptor objects | 10:01.13 |
| paulgardiner | s/tow/two | 10:01.36 |
| tor7 | do you mean to pass both the page and xobject resource dictionaries? | 10:02.07 |
| | I think the PDF interpreter only looks in the xobject resources if they exist, and only looks in the page resource dict if there isn't an xobject resource dictionary at all | 10:02.41 |
| | that was a long and convoluted sentence... | 10:02.57 |
| paulgardiner | tor7: that sounds the correct thing to do | 10:03.16 |
| tor7 | define "that" | 10:03.37 |
| | passing two resource dicts would be the wrong thing to do | 10:03.51 |
| | but you're hopefully referring to my previous statements :) | 10:04.04 |
| paulgardiner | tor7: I meant pass in a resource that can be searched for already usable things in addition to the one that gets built up during the use of the device | 10:04.13 |
| | I think this was your and Robin's suggestion, in fact. :-) | 10:04.42 |
| tor7 | oh right, a global "we've seen these resources before, use them from here" dictionary, but don't use the actual dictionary in the pdf | 10:04.55 |
| paulgardiner | Yep | 10:05.04 |
| tor7 | right. yes. I think we discussed that a week or two back, yes. | 10:05.16 |
| paulgardiner | But I didn't want to do that yet seeing as I'm just creating simple base14s | 10:05.30 |
| tor7 | fair enough | 10:05.37 |
| | I was (as part of that) also advocating just looking through an existing resource dictionary (a regular one) for matching font descriptors | 10:06.07 |
| | but I guess that amounts to the same code being used | 10:06.21 |
| | so for later | 10:06.32 |
| paulgardiner | Sorry, I didn't understand how the "also" suggestion differs from the previous one. | 10:07.27 |
| tor7 | look for existing object in page resources; not found, then look for existing object in global resource list and copy to page resources. | 10:08.09 |
| | same looking code, just in a different place and with a slightly different outcome | 10:08.35 |
| | use as is, in the first case. copy with a new name, in the second. | 10:08.58 |
| paulgardiner | But still doesn't that require passing in a secpnd resource to the pdf device? Or can it find it from the fz_text obj | 10:09.05 |
| tor7 | the pdf device has a resource dictionary attached to the page (or content stream) it's writing to | 10:09.51 |
| | doesn't it? | 10:09.59 |
| Lupo | hi there. quick and fast question: | 10:10.08 |
| tor7 | paulgardiner: pdf_device->resources | 10:10.36 |
| paulgardiner | tor7: Yeah, but that's the one that gets things added to it | 10:10.51 |
| Lupo | is it possible @ now to install gs for gimp on win8 to open .eps files? | 10:11.06 |
| tor7 | paulgardiner: forget my ramblings, I'm confusing the two sides of the interface | 10:11.15 |
| paulgardiner | tor7: Another idea was to preload that. | 10:11.19 |
| tor7 | the pdf device does the right thing already | 10:11.23 |
| | (it reuses fonts it's seen on the same page already) | 10:11.38 |
| paulgardiner | Ah right. yes | 10:11.51 |
| tor7 | we may want to preseed the pdf_device->fonts list from a resource dictionary at setup time | 10:12.15 |
| paulgardiner | Yeah. Various possibilities | 10:12.46 |
| tor7 | I was (in a muddled state) thinking about how to reuse font objects for the text appearance annotations | 10:12.54 |
| | maybe all these places should have some "find me a good font descriptor for XYZ" function | 10:13.17 |
| paulgardiner | tor7: Welcome to my world. :-) | 10:13.17 |
| tor7 | Lupo: no idea, but if you mean real win8 (not the crippled winrt arm version) it ought to work out of the box just like on win7 and earlier. | 10:14.02 |
| | I don't know if gimp has done something special on win8, but if it's a "desktop" as opposed to "metro" app it should just work | 10:14.41 |
| | paulgardiner: anyway, I've commented on the things that need fixing. with those fixed it should be good to go. | 10:15.15 |
| | but we ought to be working on a non-master branch while the release candidate is settling | 10:15.28 |
| paulgardiner | okay. Got a name in mind? | 10:17.33 |
| tor7 | unmaster? | 10:18.33 |
| paulgardiner | Another way would be to have a release branch. Makes little difference really | 10:23.09 |
| | Are you thinking we'd bring them together with merge or rebase? | 10:23.56 |
| tor7 | merge, if there are any critical bugfixes on the release branch | 10:24.25 |
| | so we could do a release branch if we need to add bugfixes to the RC | 10:24.38 |
| | and keep working on master | 10:24.44 |
| paulgardiner | yeah, sounds good | 10:25.43 |
| | So if no critical bug fixes needed, then eventually the rc will get also tagged as the final release. If there are critical bug fixes, we create a release branch at the rc point and merge all changes on that branch to master? | 10:28.08 |
| | tor7: repushed with your suggested changes, if you just want to check them over. Also pushed a previous branch with old version so that you can just diff if you like | 10:46.22 |
| tor7 | paulgardiner: yes, that's the idea. | 10:53.12 |
| paulgardiner | Ta | 10:53.24 |
| | Hang on, that was probably a reply to "So if no..." | 10:54.03 |
| tor7 | paulgardiner: consider it a reply to both :) | 10:55.33 |
| paulgardiner | :-) | 10:55.42 |
| | tor7: Wah! I just pushed one to many commits to golden. As anyone got "force access" to reset it back one? Or do I need to commit a reverse of the last? | 10:58.47 |
| | s/As/Has/ | 10:58.55 |
| tor7 | paulgardiner: just push -f to golden | 10:59.12 |
| | there's no special access right required | 10:59.16 |
| paulgardiner | Oh okay. Ta | 10:59.26 |
| tor7 | if you do it fast enough, but it sometimes gives the cluster a hickup | 10:59.30 |
| | we've done it often enough that it should be routine procedure by now :) but I think only robin and marcosw have the know-how how to fix the cluster hickups | 11:00.13 |
| paulgardiner | Phew! Hopefully that was fast enough. | 11:00.33 |
| tor7 | at least it's early enough in the day that any cluster hickups won't affect too many people :) | 11:01.00 |
| paulgardiner | the two rogue commits are still in the cluster queue | 11:01.50 |
| tor7 | paulgardiner: yeah, they will be tested. the question is what happens when we push after and the history isn't linear anymore. | 11:02.50 |
| | I think one of the failure modes we had early on is that it retests every commit in the history :) | 11:03.22 |
| paulgardiner | Hmmm quite | 11:03.25 |
| | Oh brilliant. I'm going to be popular | 11:03.43 |
| | ... not | 11:03.47 |
| | tor7: It would be useful if we could talk about the "text overrunning bounding box" problem later. Ping me when it's a good time. I know the cause now, but I can see two possible solutions and am unsure which is the best. | 11:29.01 |
| chrisl | Lupo: Sorry, missed your question earlier: TBH, I've no idea. You're best bet would be to ask either the gimp Windows port maintainer, or the maintainer of the plugin. | 11:45.18 |
| tor7 | paulgardiner: now is fine. | 12:07.10 |
| paulgardiner | tor7: Right. Actually have three possible solutions. What's going on is that pdf_measure_text returns the exact bounding box of the text (NOT including the little gap between the initial writing pos and the start of the first char). I use that to derive the bounding rect for the annotation. Then when creating the appearance stream, I create text using the bottom left of the bounding rect as... | 12:14.04 |
| | ...the iniital writing pos. | 12:14.06 |
| | So the text is offset by the iniital gap. | 12:14.19 |
| tor7 | ohhhh | 12:14.36 |
| | yes, that makes sense | 12:14.39 |
| paulgardiner | Sol 1. zerp the bottom left of the rect before using it as the annotation rect. | 12:14.56 |
| | Sol 2. Change pdf_measure_text to just sum the advances. | 12:15.17 |
| tor7 | doesn't the baseline also shift then? | 12:15.21 |
| paulgardiner | Sol 3. In layout text, be more careful about positioning. | 12:15.39 |
| | I'm not sure why I'm not seeing probs with base line. Perhaps just because I didn't text with y or g etc. :-) | 12:16.14 |
| tor7 | I'd expect that with the baseline at the bottom of the bounding rect the new text would be "face->descent" lower down on the page | 12:16.55 |
| paulgardiner | Yeah, I expect so. I'll check that later | 12:18.03 |
| | Or now even. | 12:18.16 |
| tor7 | my suggestion (given my limited understanding here) would be to make pdf_measure_text measure the advance widths only, and then use the font->ascent/descent to position the baseline and bounding box relative to each other | 12:19.12 |
| | so text->y would be derived from bbox->top + font->ascent | 12:19.42 |
| paulgardiner | Ah good. I think that's my prefered solution too. | 12:19.44 |
| tor7 | and text->x woul/d be bbox->left + text advance | 12:19.57 |
| | and baseline offsets for multiple lines would be face->height (or (descent+ascent)*1.2) | 12:22.43 |
| paulgardiner | That should make text fit "nicely" in the bounding rect, with natural gaps all around | 12:22.50 |
| | tor7: oh okay. Useful to know. | 12:23.11 |
| tor7 | and if you need to make a new bbox to adjust for the height, the lowest baseline + descent | 12:23.22 |
| | now, we probably ought to work on cleaning up the fz_font struct and functions around it. but that's something we can deal with later if you want. | 12:24.18 |
| paulgardiner | Probably, because I'd like to get a first version of the signature stuff ASAP | 12:24.59 |
| tor7 | preferably before we implement non-base14 fonts | 12:25.25 |
| | what we have now will do until then | 12:25.30 |
| paulgardiner | Right. I'll give it a go. | 12:26.33 |
| tor7 | given robin's (and yours, I guess) hate of fonts feel free to dump that bit of work on my desk | 12:27.25 |
| paulgardiner | See how it goes. I don't hate fonts that much. It's just a case of reminding myself how it all works. | 12:28.47 |
| | tor7: I'm seeing descent = ascent = 0.0. Looks like these are present only if the Ascent and Descent are in the PDF file. Do I need to do an FT call? Also this needs to work for all fonts (not just base14) because pdf_measure_text is used by the forms code. | 12:45.41 |
| tor7 | ah, yeah. | 12:46.32 |
| paulgardiner | I'd imagine they are always present in the PDF file for Type 3s? | 12:47.03 |
| tor7 | ascent/descent are part of the pdf_fontdesc struct, and I guess you don't have that? | 12:47.04 |
| paulgardiner | I do have that | 12:47.22 |
| tor7 | or if you do, we can set the pdf_fontdesc ascent/descent from the ft_face if they're not set in the PDF | 12:47.35 |
| paulgardiner | Oh yeah. That would be good | 12:47.51 |
| tor7 | at the end of pdf_load_font_descriptor | 12:47.52 |
| | if (fontdesc->ascent == 0) fontdesc->ascent = (float) face->ascent / face->units_per_EM; | 12:48.40 |
| paulgardiner | Excellent. That easy! | 12:49.07 |
| tor7 | though in theory, ascent and descent are required entries in a font descriptor | 12:51.38 |
| | but optional for type3 fonts | 12:51.45 |
| | descent is supposed to be negative according to the spec | 12:52.04 |
| | which is a bit of a gotcha | 12:52.18 |
| | I believe the freetype face->descent is positive | 12:52.27 |
| | I think we can safely delete cap_height and x_height (as we don't use them) and add in fontdesc->leading (which is in the spec, but we don't read) | 12:53.43 |
| | font_weight is also not read (it's newer in the spec than the code that reads fontdescriptors in mupdf... introduced in 1.5), but may be useful | 12:54.45 |
| | in fact, if you're updating this delete all but the entries we want to use | 12:55.45 |
| sybariten | What would be the most active or suitable channel for discussion about postscript in general? | 13:22.45 |
| chrisl | sybariten: I doubt there's a really active Postscript "venue" - not that people using it, and even fewer using it "properly"..... comp.lang.postscript has seen an increase in activity recently. Or stackoverflow | 13:26.08 |
| | s/not that/not that many | 13:26.21 |
| sybariten | i see | 13:28.00 |
| chrisl | sybariten: in general we don't mind discussing Postscript here, but we're not keen on being used as substitutes for reading the PLRM! | 13:28.32 |
| sybariten | well i know nothing about PS really, but i just learned that i can (to my surprise) use negative values in "bounding box" to take an already rendered eps file, and give it more white space offset | 13:28.57 |
| chrisl | sybariten: that's not really the correct way to do that - the bounding box should be the smallest rectangle enclosing the marks in the EPS..... | 13:30.14 |
| sybariten | chrisl: i suspected it would not be considered very sophisticated! | 13:31.02 |
| chrisl | It would be preferable for the calling PS code to move the origin appropriately so you get the contents positioned as required | 13:31.15 |
| sybariten | But imagine this dilly of a pickle | 13:31.33 |
| | i have a system generating ps (eps) files of diagrams ... and for some reason, things are "too close to the left border". If you think of a Y axis, the numbers there get slightly cropped if they are of a bigger font, etc | 13:32.28 |
| | when inspected in adobe illustrator its appearent that the information is there, the characters arent actually "chopped off" ofcourse, its just that there are limits or boundaries that show them like this. | 13:33.08 |
| chrisl | Hmm, I would say that your system is getting the bounding box incorrectly - given that the bounding box units are fairly course, it sounds like the system is rounding the numbers up instead of down - guessing, of course. | 13:34.12 |
| | Or is clamping the bounding box to zero and higher number | 13:34.56 |
| sybariten | now, if i have " %%BoundingBox: 0 0 396 144 " and " 0 0 396 144 rectclip " set up already from the beginning....i'm thinking all drawing will originate from this, too | 13:35.40 |
| chrisl | Erm, not exactly - but anything outside that will be clipped | 13:36.32 |
| | sybariten: note that the BoundingBox values and the rectclip are totally independent - it just happens, in this case, that the match | 13:37.54 |
| sybariten | ok | 13:38.17 |
| chrisl | In a "normal" Postscript interpreter, the BoundingBox is just comment, and is ignored. The rectclip is an operator, and will be acted upon | 13:38.50 |
| sybariten | well, i dont knwo how to best explain this, but my idea was simply that first these boundaries are set up, and then a lot of _curves_ are drawn inside of them. And i thought it would be easier to inflict the offset to the boundaries, with a negative value, thant to translate all of the curve drawing, if you see what i mean? Then i'd have to change each value thats related to hwo a curve is | 13:39.29 |
| | drawn..... | 13:39.31 |
| chrisl | sybariten: it really depends on how the Postscript is written: moving the curves *may* be a single operator..... "translate" | 13:41.00 |
| sybariten | oh really? But i mean... there is a bunch of curcves in an image... something like "translate everything drawn hereafter, +10 and +10" or how do you mean? | 13:41.54 |
| chrisl | sybariten: the translate operator moves the origin | 13:42.38 |
| sybariten | hmmmm ok | 13:43.07 |
| chrisl | sybariten: but as I said, if parts of the marks are being clipped, then the rectclip values, I would say, are wrong | 13:44.39 |
| sybariten | ok | 13:45.58 |
| | yeah well this PS implementation is prolly far from perfect.... | 13:46.10 |
| chrisl | sybariten: so, how badly are the marks being clipped? | 13:46.36 |
| sybariten | chrisl: i can show you the file if youre interested | 13:47.14 |
| | i find these issues a bit tricky to explain in words... sometimes | 13:47.27 |
| chrisl | sybariten: if it's not too big, sure | 13:47.37 |
| sybariten | 5 kilobytes i think | 13:47.42 |
| chrisl | That's fine | 13:47.54 |
| sybariten | whats the simplest file uploader today? | 13:54.16 |
| chrisl | We usually use http://pastebin.com/ or you can e-mail it | 13:55.07 |
| sybariten | hmm hmm but pastebin isnt optimal if you actually have a file, is it? You mean i'd paste all the contents then... hmmm | 14:00.42 |
| chrisl | Like I said, e-mail works, too | 14:00.57 |
| marcosw1 | paulgardiner: I noticed a problem with your latest cluster job, give five minutes to fix it and then you can repush. | 15:58.54 |
| paulgardiner | marcosw1: Is that the one from c 10 mins ago? | 16:00.00 |
| marcosw1 | yeah | 16:00.07 |
| | the bmpcmp job generated a "log file too big" error and the cluster job aborted | 16:00.25 |
| paulgardiner | I don't know if it's related but earlier today I accidently pushed 3 commits when I intended 2 and had to reset back one. | 16:01.19 |
| marcosw1 | any idea why the file tests_private__pdf__forms__v1.6__cafa_acaa_v2.0.mjs would generate millions of messages like this: warning: cannot encode character with code point 0x206d | 16:01.24 |
| paulgardiner | marcosw1: Well a mistake in the code I've been working on lately could cause something like that. | 16:02.37 |
| | I'll test that file locally to see what's going on. | 16:02.54 |
| marcosw1 | in the past we've had issues with cluster nodes filling their hard drives when warnings and/or debugging messages have caused large log files to be generated, so the cluster now checks for large log files and aborts the run. a better solution would be just to kill the job(s) which are the problem, but because of an internal limitation in the cluster code that's tricky. | 16:04.33 |
| | paulgardiner: commit 161e50f5cf is the one that shouldn't be there, correct? I'll roll the cluster back to d812f7 and let it re-run the two commits you intended to push. | 16:06.10 |
| paulgardiner | That's the one. | 16:06.55 |
| | The cluster testing with that included would certainly explain the large number of warnings. | 16:07.59 |
| marcosw1 | I really wish we used a version control system that didn't allow you to re-write history :-) | 16:08.57 |
| paulgardiner | We could make that a policy. I could easily have pushed a reverse of the commit. | 16:10.38 |
| | And locally I could have a policy of trying to avoid ever putting anything on master that wasn't ready to commit, to try to ward off accidents | 16:11.49 |
| marcosw1 | no, it doesn't happen enough to worry about, and like everybody else I like having a clean commit history. The problem is that the cluster code was written when we used svn, and I don't think it allowed mucking with the repository in this way, so it wasn't allowed for. | 16:12.04 |
| | well, I still haven't figured out how to correctly deal with the log file too big issue, but at least the cluster is back to being in sync with the mupdf repository (or at least it will be when the queued jobs are finished). | 16:13.49 |
| paulgardiner | marcosw1: Brilliant. Thanks. And appologies for the cock up. | 16:14.31 |
| marcosw1 | no worries. | 16:14.46 |
| paulgardiner | Do you mean that the "log file too big" errors are still appearing? | 16:14.59 |
| marcosw1 | paulgardiner: I don't think so. | 16:38.58 |
| paulgardiner | marcosw1: Oh good. Okay to retry? | 16:39.36 |
| henrys | marcosw1:I wonder if a live test directory can be exported for network mount somewhere? | 16:53.25 |
| mvrhel_laptop | chrisl: so the program did not run on the arm surface | 17:08.21 |
| | I don't have any reasons why to help you though | 17:08.48 |
| chrisl | mvrhel_laptop: no errors or such? | 17:09.50 |
| mvrhel_laptop | no errors. it just said it could not do it. I tried as administrator | 17:10.22 |
| chrisl | Hmm, maybe it doesn't have command prompt? | 17:10.43 |
| mvrhel_laptop | of course I don't have the surface on me now, to give you the exact message | 17:10.55 |
| | if you want, I will do it again when I get back from coffee shop | 17:11.15 |
| chrisl | No, let's leave it. I wasn't exactly confident it would run anyway. We'll see whether the arch.h I've got in there works at some point ;-) | 17:12.02 |
| marcosw | I'm going to take bugzilla down for a memory upgrade and installation of a ups. It should be back up in 15 minutes or so. | 18:09.48 |
| ray_laptop | Darn. The trio sprintf appends a "0x" on the front of the number value. That breaks read mode fopen with memory based clists (I use %p format to print the address as a filename string). sscanf (filename, "%p", addr) stops at the 'x' and always returns 0 | 18:17.59 |
| | well, maybe it is just windows funkiness | 18:24.04 |
| tkamppeter | Anyone knows when GS 9.08 will have FF and when it will get rel;eased? | 18:56.04 |
| | Ubuntu FF is end of August (29 AFAIR). | 18:56.28 |
| ray_laptop | yep, that's the issue. linux AND trio write out %p with leading "0x" but windows writes %p the same format as %08x -- just the 8 hex characters | 19:06.19 |
| | so gxclmem.c broke when we switched to using the trio for sprintf :-( | 19:07.07 |
| | so does trio have an sscanf ? | 19:08.24 |
| ray_laptop | goes to look | 19:08.28 |
| | guess it does. Adding gs_sscanf to our little group of gs*sprintf functions | 19:16.19 |
| mvrhel_laptop | tkamppeter: chris is planning to create the release branch in the next couple days | 19:17.12 |
| | and of course I have a P1 segv bug dropped in my lap days before the release :( | 19:17.56 |
| | one of the new sumatra test files | 19:18.33 |
| tkamppeter | mvrhel_laptop, I want to change one thing: I want to move the gstoraster CUPS filter from GS to cups-filters as now it will need libcupsfilters. Perhaps I also move gstopxl and all associated files, leaving only gdevcups.c and cups.mak in the cups/ directory of GS. | 19:20.37 |
| mvrhel_laptop | tkamppeter: you probably should work with chrisl on this. he will be back online tomorrow your time (assuming you are in europe now) | 19:22.14 |
| tkamppeter | mvrhel_laptop, OK, thanks. | 19:23.15 |
| mvrhel_laptop | well Adobe generates an error with this file. I guess I need to see what is going on and make sure we generate an error before we get to a segb | 19:27.02 |
| | segv | 19:27.04 |
| | lunch time | 19:27.14 |
| | bbiaw | 19:27.16 |
| ray_laptop | wonders how any files that used pattern-clist mode were working. They use memory based clist | 19:28.21 |
| | bbiaw | 19:30.36 |
| | my segfault with PCL and --saved-pages-test mode is fixed. Works as well as gs now. Next try and figure out which differences are real :-( | 20:56.35 |
| | Forward 1 day (to 2013/07/30)>>> | |
IRC Logs