| <<<Back 1 day (to 2013/07/16) | 2013/07/17 |
vtorri | chrisl: hey | 06:54.38 |
| chrisl: fyi, it seems that now, my module can be linked against libgs (contrary to the dll provided by the prebuilt binaries) | 06:55.13 |
| but there is something strange, though, the linker is giving plenty of warning messages | 06:55.38 |
| i'll ask the mingw-w64 guys about them | 06:55.50 |
chrisl | vtorri: I don't think there were any serious linker warnings from the the "stock" applications. | 07:03.03 |
Guest58449 | hello | 07:04.33 |
| I want following features in pdf hightlight text, ink, note taking, bookmarks, zoomIn/zoomout and night mode. | 07:06.52 |
| I have downloded source code fromhttp://www.mupdf.com | 07:07.20 |
vtorri | chrisl: well, i've never seen this, so i'm wondering why they are thrown :) | 07:07.36 |
Guest58449 | Actually I want those all features for android platform. | 07:08.12 |
chrisl | vtorri: well, I think you're doing the right thing, asking the mingw64 devs. | 07:08.32 |
vtorri | yes | 07:08.44 |
Guest58449 | I have successfully run android code also. | 07:09.46 |
chrisl | vtorri: I was just going to do a build to check for linker warnings, but "make soclean" failed to remove the sobin directory, and I can't delete it any other way :-( | 07:10.27 |
Guest58449 | but I found there are some of the feature not available that I want like note taking, bookmarks and night mode. | 07:11.08 |
vtorri | chrisl: note that the warnings i have are when i link my module against libgsn not when building libgs itself | 07:11.21 |
Guest58449 | How can I implement that? | 07:11.34 |
vtorri | chrisl: it fails to remove a dir ?? | 07:11.41 |
kens | Guest58449 : you can modify the source code, its open source. | 07:11.56 |
chrisl | vtorri: yeh, then I try to remove it other ways, and Windows gives it the "you need to be administrator", "you don't have permission" ad nauseum..... | 07:12.37 |
vtorri | chrisl: and i guess that you were a user when you've run make so | 07:13.29 |
Guest58449 | yeah I know that but that code is so big....Exactly in which file I will need to change? | 07:14.19 |
chrisl | vtorri: Yeh, this is Windows7 so administrator is that strange virtual user. I've seen this kind of thing before, and a reboot usually resolves it. But, of course, there are updates pending, so it's taking a while! | 07:15.10 |
vtorri | chrisl: no problem here | 07:15.17 |
chrisl | vtorri: No, it's worked loads of times here, just a another intriguing bit of Windows madness...... | 07:16.06 |
vtorri | :) | 07:16.21 |
chrisl | vtorri: I was just going to say that there might be some od mismatch of CFLAGS/LDFLAGS causing your warnings. | 07:17.16 |
Guest58449 | In android market there is one app "pdf annotation". In these app there is note taking/comments available. And this app is based on mupdf. | 07:17.34 |
| but the pdf parsing mechanism is different. | 07:17.52 |
| when I add annotation using "Pdf annotation" app that not visualize in mupdf android pdf app that I downloaded from site. | 07:18.49 |
vtorri | chrisl: maybe | 07:19.31 |
Guest58449 | Please can any one help me? | 07:20.42 |
| how to combine that both code? | 07:20.57 |
kens | Guest58449 : No we can't help you 'combine the code'. We don't know anything about the "pdf annotation" application. | 07:21.32 |
Guest58449 | :( | 07:23.01 |
kens | Guest58449 : if you have specific questiosn about the MuPDF code, the developers will try to answer your questions, but your current question is much too broad | 07:23.08 |
Guest58449 | ok ... Is any way to achive note taking using mupdf. I mean can you tell me how can use this library to create my own pdf parser. That will also help me. on site there is no more documentation. | 07:24.54 |
kens | Guest58449 : MuPDF *is* a PDF parser, you don't need to implement another one. What you need to do is add additional code to handle the features you want. I am not one of the MuPDF developers so I'm not really ablle to guide you specifically. But the ability to add notes means some adding annotations of some kind. This featreu is in development at the moment, some things work, some don't. | 07:26.53 |
| You will need to fully understand the MuPDF Application Programming Interface, and begin to learn the internal structures. This will help you understnad what you will need to modify, and which functions are available, to create a modified PDF with the additional annotations you want | 07:28.03 |
Guest58449 | ohh god...mupdf code is so big. :( | 07:32.37 |
| Kens.. may I provide you pdf annotation app url that based on mupdf library? | 07:33.14 |
vtorri | are the stdio callbacks thread safe ? | 07:37.08 |
| or should I lock / unlock when necessary ? | 07:37.23 |
| (when i set them) | 07:37.32 |
Guest58449 | https://play.google.com/store/apps/details?id=cx.pdf.android.pdfview | 07:37.54 |
| this app also based on mupdf | 07:38.17 |
| what is freetype overlay? | 07:42.53 |
chrisl | vtorri: I don't believe we lock around uses of the callbacks, so it really depends what you do in your implementation whether you need mutexes there or not | 07:48.57 |
kens | Guest58449 : I am not a MuPDF developer, I can't have any useful opinions on the code. | 07:50.49 |
| I don't see naythign on that web site which says itts based on MuPDF | 07:51.27 |
| FreeType is a rendering library for fonts. | 07:52.03 |
| Ah, APV Viewer is based on MuPDF. | 07:52.25 |
| Well one approach would be to just look at what the PDF Annotation code actually does. | 07:53.29 |
Guest58449 | you can download code from https://code.google.com/p/pdf-annotation/source/checkout | 08:20.23 |
kens | Guest58449 : feel free. | 08:20.44 |
| As I have said, the developers will probably be willing to answer any specific questions you have about the MuPDF code. They are not going to do the work for you. If you want to add features to MuPDF, then please do, if you feel its useful enough to be made public then you can offer it back to the developers, they may be happy to accept it into the code base. | 08:22.34 |
sebras | Guest58449: if https://play.google.com/store/apps/details?id=cx.pdf.android.pdfview already exists, why do you need to develop a new note taking app using PDF? if I may ask. I'm always curious. :) | 08:28.07 |
kens | sebras I think he said that MuPDF didn't render the annotations afterwards. | 08:28.40 |
sebras | kens: right. one never knows when a potential customers pops in here, hence me asking. | 08:31.45 |
Guest58449 | yeah this is already available but in this there in no feature of highlighting and ink. | 08:32.55 |
| I want note taking as well as highlighing and ink writing. | 08:33.31 |
| how can I contact to mupdf developers? | 08:34.13 |
kens | You already are | 08:34.25 |
| This channel is logged and al the developers read the logs | 08:34.36 |
| But vague and open ended questions like 'how can add this feature' are not likely to get answered because it woudl take as long to answer teh question as write the code, and teh developers do have other work to do | 08:35.27 |
Robin_Watts | Guest58449: I am one of the mupdf developers. | 08:35.44 |
kens | If you look at the note-taking app source code, you can see what was done to add this to MuPDF. You can then add that yourself either to MuPDF itself or to another application based on MuPDF. | 08:36.10 |
Robin_Watts | We are already working on annotations etc, but other things are higher priority at the moment. | 08:36.19 |
| We support some types of annotation, but not others. | 08:37.16 |
| Support for the others will come. | 08:37.25 |
| If you want to add support yourself, great. | 08:37.36 |
| You will need to make changes both in the main library (source/pdf/pdf-annot.c is probably a good place to look) | 08:38.06 |
| and in the C<->Java interface (platform/android/jni/mupdf.c) | 08:38.24 |
| and in the java code (platform/android/src/com/artifex/mupdfdemo/*.java). | 08:38.55 |
Guest58449 | Ah!!! :))) thats I want.... Actually mupdf library is so big...so that why I'm not getting in which files I will need to change for annotation. | 08:40.25 |
| you are rock robin thanks a lot its really means a lot. | 08:41.10 |
Robin_Watts | no worries. | 08:41.36 |
Guest58449 | Actually I'm also new in jni ...but I'll take a look into this | 08:41.39 |
| I never build such code ...It's really a big success that I'm able to run that code. | 08:42.26 |
| If I'll get any issue may I ask you? | 08:43.16 |
sebras | Guest58449: ask here, and if someone has some spare time to help you we will. :) | 08:43.59 |
Robin_Watts | sure. Ask away. How much help I can give depends on how much time I have though. | 08:43.59 |
Guest58449 | ok :)) | 08:44.51 |
Robin_Watts | Late night henrys_? | 08:46.20 |
kens | very early morning, maybe insomnia ? | 08:46.34 |
sebras | or sleep walking/computing. | 08:46.51 |
Robin_Watts | Just added Takane-san to the skype group. | 08:47.03 |
kens | Bye folks | 09:25.32 |
Robin_Watts | I think I may have an idea about this lcms "threading" thing. | 11:52.16 |
| Marti handles memory allocations by keeping a set of static pointers to functions to do the mallocs/frees etc. | 11:53.01 |
| So if you have multiple threads accessing memory functions you're fine, as long as they all use the same memory access functions. | 11:53.28 |
chrisl | Oh, that's really bad :-( | 11:53.48 |
Robin_Watts | When you have 2 different callers to the same lib, they fight over who gets to set the statics. | 11:53.49 |
| Yes. | 11:53.52 |
| So... I have a workaround here where I tweak the source to give our version a different prefix for those variable names. | 11:54.22 |
| I'll get that tested, and if it works, pass it up to marti. | 11:54.39 |
| The problem is, I don't think his API admits of solving it properly. | 11:54.52 |
chrisl | I take it lcms doesn't have a "context"? | 11:54.59 |
Robin_Watts | chrisl: It has a context, but that is just a void * that is passed into any callback functions. | 11:55.34 |
| including the memory allocator ones. | 11:55.48 |
| so you can't put the memory allocators in the context. | 11:56.02 |
| because he still supports all the calls with no context passed in. | 11:56.16 |
chrisl | That's not what I'd consider an lcms context - I can't see how it can be properly thread safe without it's own context | 11:56.38 |
Robin_Watts | it's thread safe, as long as all threads agree on the memory allocators to use. | 11:56.59 |
| but yes, it's a horrid hack, and I did try to point out the problems to him ages ago, but he wasn't having any of it. | 11:57.49 |
| and I didn't feel I could really hammer on the point too much. | 11:58.12 |
chrisl | Well, It should be reported to Marti, not us | 11:58.17 |
Robin_Watts | I've contacted the reporters. | 11:58.37 |
| If they will test my fix, and it solves it, we can pass it up the chain to Marti. | 11:58.52 |
chrisl | It's not really a "fix" though, really a workaround at best :-( | 11:59.29 |
Robin_Watts | oh yes, absolutely. | 11:59.45 |
chrisl | There really is a fundamental flaw in the library | 12:00.12 |
Robin_Watts | indeed. | 12:01.57 |
| There is no way to fix it without a change to his APIs though, and I can't see him wanting to do that. | 12:02.52 |
chrisl | Well, you have a real world use case that shows the API is broken | 12:03.46 |
Robin_Watts | A better workaround would be to extend my hacky workaround so that ALL the non-static functions in the lib have the #define hackery to rename all the symbols. | 12:04.17 |
chrisl | Either that, or we will have to revert to locking around calls to lcms :-( | 12:05.19 |
Robin_Watts | It's not just us that would have to lock around lcms. | 12:05.38 |
| It's all callers would have to lock. | 12:05.48 |
| and currently there is no way to read the current memory plugin state. | 12:06.09 |
| i.e. you can insert your new alloc functions, but you can't store the old ones, and insert new ones. | 12:06.31 |
chrisl | True, my point is all users would have to treat lcms as non-thread safe | 12:06.36 |
Robin_Watts | chrisl: yeah. | 12:06.44 |
| The best solution would be for him to do an lcms3.0 with a fixed API. | 12:06.58 |
chrisl | Yes, ASAP! | 12:07.09 |
Robin_Watts | The changes don't need to be huge. | 12:07.11 |
tor7 | paulgardiner: the pdf creation device should look up the fz_font in its resource dictionary (and insert an entry if missing) when it gets text from a fz_text object | 14:09.29 |
| I think the biggest headache there is the fact that fz_text has a fz_font, whereas the stuff used in the pdf interpreter (and I guess pdf writing device) should be a font descriptor | 14:09.57 |
| you'll have to poke Robin_Watts, but I think it should be possible to look up the fz_font in the pdfwrite device's resource dictionary somehow | 14:10.33 |
Robin_Watts | is poked | 14:10.45 |
kens | tor7 where does an appearance stream get its resources dictionary from ? I've just beenlooking that up in the PDF reference and I can't see it | 14:11.00 |
paulgardiner | kens: look under form X objects | 14:11.52 |
kens | paulgardiner : ah... | 14:12.00 |
paulgardiner | I was just looking too. :-) | 14:12.07 |
kens | Obviously I was prompted by your email | 14:12.21 |
Robin_Watts | The pdf writing device gets called with fz_font's. | 14:12.28 |
| and there is currently no way to get to a font descriptor from them. | 14:13.07 |
| I think we probably need to extend fz_fonts in some way, akin to the way we can get the original data out of an fz_image. | 14:14.01 |
| but the problem is that I understand images, where I really don't understand fonts :) | 14:14.19 |
paulgardiner | tor7: I don't fully get how we insert missing ones. Do we need to reembed the entire font? | 14:14.38 |
Robin_Watts | paulgardiner: There is currently no code to ensure an fz_font is in the resources for a page/appearance stream etc. | 14:15.41 |
paulgardiner | I think my forms filling code will fail (throw exception I hope) if it isn't there | 14:16.30 |
| I mean the appearance stream genation code for cases where forms have been filled in | 14:18.07 |
| I guess we'd ensure it if we actually create fields, but at the moment we only fill in existing ones | 14:18.42 |
tor7 | and we wouldn't load it *merely* for the sake of writing out its name, we'll (eventually) be needing all the font descriptor data to do metrics and encoding | 14:18.59 |
paulgardiner | There's a required DA attribute that says what font to use. I work under the assumption that the font is in the resource hierarchy. | 14:19.43 |
| I'm hoping that's relevant to what you just said. :-) | 14:20.06 |
tor7 | given a pdf font descriptor (which is what the annotation creation stuff would use) it should be trivial to get the fz_font out from that to create a fz_text object | 14:20.37 |
| and I'd imagine the way to get a font descriptor would be to use an existing font, or to create a new one to embed it | 14:21.08 |
paulgardiner | tor7: yes exactly | 14:21.37 |
tor7 | what I meant with inserting it into the resource dictionary is just insert an entry in the pdf dictionary to map a newly made up name to an indirect object where the original font descriptor is | 14:21.41 |
| (or where the newly created one is) | 14:21.50 |
paulgardiner | That was option 3, I think | 14:21.53 |
tor7 | paulgardiner: yes, I think option 3 is the only one worth pursuing, sorry I didn't mention that :) | 14:22.11 |
| we could extend the pdf font descriptor struct to have a pdf_obj reference to its original object | 14:22.39 |
Robin_Watts | Urm... | 14:22.41 |
paulgardiner | tor7: in the insertion case, how can the pdf device know what to map the name to | 14:22.49 |
| Ah | 14:22.59 |
tor7 | paulgardiner: shouldn't matter, it's up to the pdf device to create a resource dictionary. it could map it to whatever it wants. | 14:23.13 |
Robin_Watts | "given a pdf font descriptor (which is what the annotation creation stuff would use)..." really? currently the device only gets fz_fonts. | 14:23.29 |
tor7 | Robin_Watts: the device only deals in fz_fonts | 14:23.43 |
| but the higher level code that does appearance stream synthesis should work with pdf_fonts | 14:23.57 |
| pdf_font_descs* | 14:24.20 |
paulgardiner | Somehow fz_fill_text has to do it with what it has available | 14:24.59 |
Robin_Watts | Consider the case where we are reading an xps file in and writing a pdf file out. | 14:25.11 |
| (I know this isn't the immediate case, but it's something we're building towards) | 14:25.38 |
tor7 | hm, right. maybe I brain farted too early. | 14:26.02 |
Robin_Watts | It used to be that we passed fz_pixmaps through the device interface. | 14:26.22 |
paulgardiner | Robin_Watts: Right. Is seeding the resource impossible there? | 14:26.27 |
tor7 | in that case, we have two scenarios we want to work with | 14:26.33 |
| the fz_font comes from a pdf_font_desc that the interpreter and pdfwrite device both have in common | 14:26.54 |
Robin_Watts | and I had to change us to pass fz_images. fz_images being something a little higher level - something that we could get both the pixmap and the original image from. | 14:27.00 |
| I think we may need to make a similar slight shift with fz_fonts. | 14:27.16 |
| either we need to pass something a little higher than fz_fonts, or we need to make fz_fonts a little more powerful. | 14:27.34 |
tor7 | we may need to make fz_fonts more powerful, but let's not muddle them up with the pdf_font_desc (and xps_font) structs | 14:28.00 |
paulgardiner | So option 2 | 14:28.15 |
Robin_Watts | paulgardiner: With fz_images, I now have enough information to be able to seed the resources. | 14:28.22 |
tor7 | there is no strict need for the pdfwrite device to actually use our existing pdf_font_desc structs | 14:28.27 |
Robin_Watts | It is my belief that fz_fonts are not currently powerful enough to do that, but I hope they can be made so. | 14:28.42 |
tor7 | but given a fz_font the pdfwrite device must be able to create a font descriptor object to stick in the resource dict | 14:28.56 |
Robin_Watts | tor7: right. | 14:29.24 |
tor7 | Robin_Watts: I think the main thing missing is the font metrics, for being able to do an Identity-H embedded font from fz_font | 14:29.37 |
Robin_Watts | tor7: What I heard: "I think the main thing missing is <something about fonts that robin doesn't really understand>" | 14:30.33 |
| so I'll just nod sagely... | 14:30.42 |
tor7 | it may be useful to be able to reuse an existing font descriptor in the pdfwrite device, but I suspect it may be easier to do something more limited at the moment: | 14:30.47 |
paulgardiner | That's two of us nodding sagely | 14:30.58 |
tor7 | only allow the base 14 fonts | 14:31.00 |
| and ignore any existing fonts and font descriptors altogether | 14:31.12 |
Robin_Watts | kens and chrisl will shout at us for not embedding fonts then :) | 14:31.30 |
tor7 | always create (and cache) a very simplistic font descriptor that uses the base 14 set | 14:31.34 |
chrisl | Robin_Watts: as long they are all base 14, I won't! | 14:31.59 |
tor7 | that'll get paul gardiner up and running for annotations, but for a general pdfwrite device it's hardly good enough | 14:32.08 |
Robin_Watts | tor7: right. | 14:32.15 |
paulgardiner | Shame though because in my case I almost certainly already have the font I need | 14:32.15 |
Robin_Watts | paulgardiner: To go back to the images example... | 14:32.52 |
chrisl | paulgardiner: you probably can't safely use an existing embedded font as it may be a subset | 14:32.57 |
Robin_Watts | In an fz_image I can ask "what's the original format for this image", and get the data in that format as a block of memory. | 14:33.28 |
tor7 | there are a lot of potential gotchas with using existing fonts | 14:33.42 |
| you can't even trust them to have a reasonable encoding for one | 14:34.05 |
Robin_Watts | If it's a format that I understand, I can write it out. If it's not, I get it as a pixmap and compress that. | 14:34.05 |
tor7 | and they may, as chrisl points out, be subsets | 14:34.15 |
Robin_Watts | Having a similar kind of scheme for fonts might work... being able to say "what format is this font?" and "is it a subset?" | 14:34.45 |
paulgardiner | chrisl: Good point. In the case I'm looking at, I probably can because they are base fonts, but that's the case that tor7's idea supports. Still seems a shame when all I really want to do is wriite "Helv" | 14:34.57 |
chrisl | paulgardiner: usually, base 14 fonts aren't embedded | 14:35.29 |
tor7 | Robin_Watts: the pdfwrite device has two use cases here IIRC -- 1) create a brand new pdf, 2) create new appearance streams for an existing pdf | 14:35.34 |
Robin_Watts | tor7: Indeed. | 14:35.42 |
paulgardiner | chrisl: oh yeah. Sorry did I say embedded. I didn't mean embedded necessarily | 14:36.02 |
tor7 | for case 1) we need to preserve fonts by being able to create new font descriptors and embed the font data | 14:36.08 |
| for case 2) I think we can get away with just doing the base14 set | 14:36.16 |
paulgardiner | chrisl: ah you said embedded. I missed that | 14:36.24 |
Robin_Watts | (I will be the first to admit that I'm out of my depth with font details, so if I talk crap, please feel free to point it out) | 14:36.25 |
tor7 | or we can get into all manners of complexity trying to reuse existing font descriptors | 14:36.46 |
Robin_Watts | For case 2, I can imagine that people might want to reuse fonts within a document. | 14:36.55 |
chrisl | paulgardiner: what I mean is relying on a font object that already exists (and will usually be from an embedded font) won't be safe | 14:37.08 |
Robin_Watts | but certainly having a solution that only worked for base 14s would be a massive step forward. | 14:37.14 |
tor7 | reusing a font can be done safely for use case 1, since we then know we won't be seeing any glyphs or encodings that we haven't got the data for | 14:37.31 |
Robin_Watts | chrisl: Can we reasonably know whether a given font object is a subset or not ? | 14:37.40 |
tor7 | but for use case 2, we need to put some limits down on the existing fonts -- like having enough of a subset, metrics and the encoding being sane | 14:38.00 |
chrisl | Robin_Watts: you can check for a subset prefix, that's *usually* used | 14:38.15 |
paulgardiner | chrisl: yes maybe I mean a font descriptor that refers to a base font, but still as tor7 points out the encoding may be a problem | 14:38.22 |
Robin_Watts | tor7: Right. Hence my question. | 14:38.24 |
| chrisl: Presumably we also easily say "do all the chars in this string appear in this font?" | 14:38.53 |
tor7 | Robin_Watts: not easily, it may be impossible to go from a unicode string to glyphs in the font | 14:39.18 |
Robin_Watts | (though I have this niggling feeling that we might be in a nightmare encoding thing here. | 14:39.20 |
tor7 | depending on how it's set up with the encodings | 14:39.27 |
chrisl | Robin_Watts: that really - remember, last ditch you get a notdef, not an error | 14:39.44 |
tor7 | in theory we could look at the fz_font freetype data, to see if we can find truetype 'cmap' tables to do the encoding to glyph id's for us there | 14:40.00 |
Robin_Watts | chrisl: Not in mupdf? | 14:40.02 |
tor7 | and then reverse map the glyphs back into the original font descriptor's encoding | 14:40.14 |
chrisl | Robin_Watts: Huh? In *PDF*, you get a notdef | 14:40.34 |
Robin_Watts | chrisl: Right, but we can map the string through, and any notdefs, we say "missing chars in the font, fall back to a base 14" ? | 14:41.21 |
chrisl | Robin_Watts: how do you know it's a notdef? | 14:41.39 |
tor7 | I would say, reuse an existing font descriptor for use case 2 IFF font is base 14 and has a known (WinAnsi) encoding, else disallow it and make our own base14 font | 14:41.40 |
Robin_Watts | tor7: we only need to come up with a scheme that works for sane input. If we bale on stupidly complex stuff, so be it. | 14:42.06 |
paulgardiner | tor7: From an fz_font object that represents a base 14 can we determine enough info to create a new font descriptor? | 14:42.08 |
tor7 | once that all works, we can start figuring out heuristics for letting more fonts in | 14:42.10 |
Robin_Watts | tor7: so what you said sounds reasonable. | 14:42.21 |
| paulgardiner: The PDF device should possibly gain some state (list of fonts that have been seen?) to avoid us generating new font descriptors every time. | 14:43.27 |
tor7 | paulgardiner: creating a new font descriptor from any old fz_font is non-trivial. doing it for a base14 font is trivial though. | 14:43.33 |
Robin_Watts | Imagine I change an annotation several times.("A" -> "B" -> "C" -> "D"). We don't want to create a new font entry in the resources every time, right ? | 14:44.03 |
tor7 | a base14 fz_font will have its data pointing to the builtin data arrays | 14:44.07 |
paulgardiner | tor7: sorry confused. I thought we had to work from an fz_font object even in the base 14 case | 14:44.16 |
tor7 | and it will not have the "is-a-substitute-font" set | 14:44.20 |
| so detecting "is-base-14" from a fz_font should be a simple check | 14:44.46 |
paulgardiner | ah right | 14:45.00 |
Robin_Watts | tor7: A simple check that involves checking the data pointer points to one of the internal tables ? | 14:45.10 |
tor7 | pdf_lookup_builtin_font() is used for both base14 and substitute fonts in some cases | 14:45.38 |
paulgardiner | it sounds like it would work, but does feel a bit hacky | 14:45.43 |
Robin_Watts | and that !is-a-substitute-font | 14:45.44 |
| it sounds like we are after a REVERSE of pdf_lookup_builtin_font ? | 14:46.01 |
tor7 | checking whether a font descriptor that uses a base14 fz_font is actually base14 needs looking at the pdf objects though | 14:46.14 |
Robin_Watts | tor7: Or it requires us to extend fz_fonts with additional fields/methods. | 14:46.48 |
tor7 | and even if a font descriptor is base14, it may have non-standard encodings | 14:46.52 |
paulgardiner | fz_fill_text just receives the fz_font. It doesn't have access to the descriptor | 14:47.05 |
| ... which may be a good thing. | 14:47.25 |
tor7 | int pdf_is_base14_font(fz_font *) to encapsulate the somewhat-hackish test | 14:47.31 |
paulgardiner | from what you are saying | 14:47.32 |
tor7 | paulgardiner: I think that's a good thing :) | 14:47.39 |
Robin_Watts | tor7: lovely. | 14:47.48 |
paulgardiner | Also we need the name not just whether it is one | 14:48.11 |
tor7 | the pdfwrite device could try to find an existing good enough font descriptor for this fz_font by looking at the resource dictionary | 14:48.13 |
paulgardiner | I think | 14:48.13 |
tor7 | and maybe cache those in a list so they can be reused | 14:48.24 |
paulgardiner | So as to create the descriptor. | 14:48.31 |
tor7 | and if no good match can be found, create a new font descriptor object | 14:48.35 |
| and save that in the list | 14:48.40 |
Robin_Watts | const char *pdf_is_base14_font(fz_font *) | 14:48.47 |
paulgardiner | yes | 14:48.54 |
tor7 | Robin_Watts: get the name out? | 14:48.58 |
Robin_Watts | NULL means isn't a base14 font, non-NULL returns the name of the font. | 14:49.01 |
tor7 | yeah. that should work. | 14:49.13 |
paulgardiner | The pdf device does something like this at present, but it always uses Helvetica | 14:49.17 |
| With the suggested addtion, it should be possible to make it handle base 14s in general | 14:49.39 |
tor7 | I have to admit not having studied how the pdf device work. I should do that some time. | 14:49.49 |
paulgardiner | Between you, you may have given me enough to carry on with | 14:50.20 |
Robin_Watts | tor7: beautifully! | 14:50.35 |
tor7 | so correct me if I'm way out of whack here, but I think the pdfwrite device should have a list of fz_font -> pdf object mappings | 14:51.00 |
Robin_Watts | Probably, yes. | 14:51.22 |
tor7 | this can be seeded from the existing page resource dictionaries by looking for base14 standard encoding font descriptors | 14:51.24 |
paulgardiner | It does | 14:51.25 |
tor7 | and when a call goes in that uses a fz_font, it looks it up there, or creates a new font descriptor when needed | 14:51.46 |
Robin_Watts | paulgardiner: Do you recreate the pdfwrite device every time you use it ? | 14:51.46 |
paulgardiner | It already does so, but always makes Helvatica fonts because it doesn't know the name | 14:51.50 |
tor7 | for base14 fz_fonts, a simple base14 font descriptor with WinAnsi encoding is added | 14:52.02 |
paulgardiner | Robin_Watts: yes | 14:52.03 |
tor7 | for any other font, we need to work some more to create an actual embedded font | 14:52.23 |
Robin_Watts | Currently the pdf device does the absolute bare minimum it can to get text out. There is a big FIXME in there. | 14:52.27 |
tor7 | or non-embedded font for when we have a substitute font | 14:52.38 |
| but I think getting the base14 cases working should get us pretty far in terms of testing and for annotation use | 14:52.55 |
paulgardiner | it does say "BIG FIXME" but does a surprising lot considering | 14:52.56 |
| It would still be nice if one day we'd be able to seed the resource and have the device recognise that an existing one is in use | 14:53.27 |
tor7 | Robin_Watts: oh yeah, now that we have the multi-page device calls in there, maybe I should pester you to go in and use them :) | 14:53.41 |
Robin_Watts | tor7: yeah. I need to look at multipage SVG output too. | 14:54.03 |
paulgardiner | Robin_Watts: if that were possible. I could carry on recreating pdf_write devices, but I'd be able to build up a single resource | 14:54.09 |
Robin_Watts | I think you'd need to create a new pdf write device each time, as different things have the resources in different places. | 14:54.50 |
| but ideally you'd want to seed them from all the other resources on that page? | 14:55.18 |
tor7 | for freetype based fz_fonts which have font data, creating truetype/type1/cff font descriptors using Identity-H encodings should not be too difficult | 14:55.22 |
| but we wouldn't want to reuse an existing font descriptor for those | 14:55.38 |
| that's too much pain and potential for crippling bugs | 14:55.48 |
paulgardiner | Robin_Watts: yes exactly, hence why it would be nice if fz_font objects were recognisable within the resource | 14:56.12 |
Robin_Watts | tor7: Again, I am nodding sagely while stroking my beard. | 14:59.10 |
tor7 | base 14! base 14!! base 14!!! ignore everything else! :) | 14:59.54 |
chrisl | Oh, ick, the contrib pcl3 device calls get_minst_from_memory() :-( | 15:10.55 |
Robin_Watts | chrisl: GS_NOT_THREADSAFE ? | 15:11.45 |
chrisl | Robin_Watts: this isn't related to threading - pcl and xps don't have a "get_minst_from_memory()" | 15:12.32 |
Robin_Watts | Ah! I see. | 15:12.45 |
chrisl | It uses it to make a change to the imager state, and I don't currently know an alternative method | 15:13.17 |
Robin_Watts | Is the imager state accessible through the device ? | 15:13.47 |
chrisl | Not that I can see - but as usual, it's a tangle of macros | 15:14.12 |
| I'll run up a debugger in a bit, and see | 15:14.40 |
Robin_Watts | I don't think it is. | 15:15.55 |
chrisl | No, I suspect not :-( | 15:16.05 |
kens | pointerr to imager state gets passed around a lot | 15:16.24 |
chrisl | kens: but into printer devices? I'm not hopeful | 15:17.00 |
kens | device calls | 15:18.02 |
| pdfwrite gets passed it a lot | 15:21.10 |
chrisl | kens: so how does pdfwrite get hold of it? | 15:21.24 |
kens | Let me look | 15:21.31 |
chrisl | kens: I suspect pdfwrite gets it from it's own enumerators | 15:21.45 |
kens | Possibly | 15:21.58 |
| Its in the show enumerator at least | 15:22.09 |
chrisl | Yeh, that's not a device call, though | 15:22.21 |
kens | ]fillpage by the look of it | 15:22.30 |
Robin_Watts | eprn currently needs it in the output_page call. | 15:23.13 |
kens | The fillpage method for a device gets a pointer to the imager_state | 15:23.42 |
| I suspect that all devices need to implement a fillpage method | 15:23.54 |
chrisl | kens: okay, thanks, I'll see if I can use that | 15:24.01 |
Robin_Watts | Can you assume that the graphics state passed to the fillpage method is still valid in the output page method ? | 15:24.47 |
kens | I am not certain. I believe it changes | 15:25.05 |
| Which is why I'm looking at the other methods | 15:25.12 |
Robin_Watts | I don't think we can rely on it being valid after any given call it's passed in. | 15:25.45 |
kens | I think pdfwrite assumes it is, at least sometimes | 15:25.57 |
Robin_Watts | Ick. | 15:26.05 |
henrys | chrisl:I would dig a little deeper and figure out why the device is doing that, I'm sure it isn't best. | 15:27.28 |
kens | fill_path and stroke_path also get a imager_state | 15:27.42 |
| also begin_image | 15:27.55 |
henrys | chrisl: we can have rayjj have a look he enjoys such things. This soft tumble stuff looks wrong to me. | 15:28.18 |
kens | All the transparency and compositor methods and fill_rectangle | 15:28.27 |
Robin_Watts | The device sets the default matrix back to unset if it's doing soft-tumble mode after printing a page. | 15:28.59 |
chrisl | henrys: okay, unfortunately, we can't just bury the pcl3 devices - apparently they are still used :-( | 15:29.32 |
Robin_Watts | We may get away with setting the default matrix back to undefined if we are doing soft-tumble mode at fillpage time. | 15:29.53 |
| i.e. move the logic from output_page into fillpage. | 15:30.25 |
chrisl | Possibly, I don't really know enough about this code to comment - seems like a mess, to me. Devices should not pull in interpreter data types :-( | 15:31.20 |
Robin_Watts | chrisl: This way, devices wouldn't need to. | 15:31.35 |
henrys | chrisl:anyway I would assign a bug to ray remove the device from your build and continue your torture. | 15:31.42 |
chrisl | henrys: I already did that - with still many hacks to be redone properly, I have a pcl6 executable built by the Ghostscript build system | 15:32.35 |
henrys | wow great news | 15:33.19 |
| his ears were ringing | 15:33.35 |
chrisl | henrys: yesterday, I was starting to wonder what I'd got myself into...... | 15:33.51 |
Robin_Watts | does anyone have a pcl3 device that does softtumbling so we can test it? | 15:34.05 |
| I guess we can write to file and diff the files. | 15:34.23 |
henrys | is that like throwing the printer down carpeted stairs? | 15:34.35 |
rayjj_ | Robin_Watts: what the heck is 'soft tumbling' ? | 15:36.17 |
Robin_Watts | I think it's duplex where we take responsibility for flipping the page image or something. | 15:37.58 |
| essentially, if we're doing it, then the default device matrix changes every page. | 15:38.17 |
| I'm slightly surprised that the default device matrix isn't recalculated every page anyway.... | 15:39.01 |
| if it was recalculated every page, then we could do away with this code entirely. | 15:39.15 |
henrys | I really wonder about some parts of my state: http://www.denverpost.com/breakingnews/ci_23676390/deer-trail-considers-hunting-licenses-drones?source=rss | 15:39.27 |
| old gomer pyle out there with a bead on a drone. | 15:40.40 |
chrisl | henrys: how could they do that when it contravenes federal law? | 15:40.45 |
henrys | it's the wild west | 15:41.12 |
Robin_Watts | henrys: Yes, because people firing rifles up into the air is just what you need. | 15:42.45 |
kens | especially at lrge chunks of flying hardware that might stop flygin afterwards | 15:43.37 |
Robin_Watts | rayjj_: The skype group was intended not for talking, so much as for everyone to be able to easily send contact requests to each other. | 15:50.40 |
rayjj_ | Robin_Watts: OK. Fair enough. | 15:58.00 |
kens | goodnight all | 16:10.29 |
Robin_Watts | tor7, paulgardiner, sebras, anyone else: robin/progressive has the progressive work on it now. | 16:42.16 |
| I *hope* that's in a form approaching being ready for commit. | 16:42.34 |
| Any comments you all may have etc would be appreciated. | 16:42.44 |
| mvrhel_laptop: Have you been following the lcms2 stuff on gs-devel ? | 16:43.06 |
| mvrhel_laptop: I was going to send Marti a mail about the problem. Will copy tech so we can all see it. Just thought I should check in case you wanted to claim ownership of the problem... | 16:49.09 |
mvrhel_laptop | Robin_Watts: I had not been following | 16:57.20 |
Robin_Watts | ok. it's not important to me that you follow it. | 16:58.01 |
| it's just important to me that you don't feel I'm treading on your toes by dealing with it. | 16:58.22 |
mvrhel_laptop | weird. I don't know if I get the gs-devel emails | 16:59.01 |
Robin_Watts | I get the emails, but I can't reply to them :( | 16:59.21 |
mvrhel_laptop | I get gs-bugs, gs-commits, gs-regression | 16:59.35 |
Robin_Watts | gs-devel is a separate public mailing list you need to subscribe to. | 16:59.52 |
mvrhel_laptop | ah ok | 16:59.59 |
Robin_Watts | essentially it's a problem with the way he has done the multi-threading stuff. | 17:00.15 |
mvrhel_laptop | Robin_Watts: ok. well that is more up your alley | 17:00.40 |
Robin_Watts | or more specifically it's a problem with the way memory allocation is handled by different callers of the lib. | 17:00.54 |
mvrhel_laptop | not really a color specific issue in any case | 17:01.15 |
Robin_Watts | not at all. | 17:01.21 |
mvrhel_laptop | Robin_Watts: but thank you for pinging me about it | 17:01.47 |
Robin_Watts | no worries. | 17:01.53 |
chrisl | Robin_Watts: do you get a bounce or something from gs-devel? | 17:01.58 |
Robin_Watts | chrisl: Thunderbird gets an error message saying that there is no gs-devel list to send to. | 17:02.23 |
| i.e it's an error at send time, not a bounce. | 17:02.40 |
chrisl | Hmm, how could TBird possible know about the existence of an e-mail address.....? | 17:03.28 |
Robin_Watts | It's an odd one. Hold on, let me find the exact message. | 17:03.43 |
| An error occurred while sending mail. The mail server responded: sorry, no mailbox here by that name (#5.1.1). Please check the message recipient gs-devel@ghostscript.com and try again. | 17:04.12 |
mvrhel_laptop | ok. I am now subscribed. funny that after 6+ years I never was | 17:04.15 |
| or at least I submitted a request for subscription... | 17:04.39 |
Robin_Watts | mvrhel_laptop: It's OK. You have a 50% chance that it'll unsubscribe you in the next month or so anyway. :( | 17:04.49 |
mvrhel_laptop | :) | 17:05.00 |
Robin_Watts | It seems to randomly take a dislike to people. | 17:05.12 |
chrisl | Robin_Watts: are you running your own smtp server? | 17:05.50 |
Robin_Watts | No. | 17:06.26 |
| I have a windows box running Thunderbird. | 17:06.46 |
| All my outbound mail goes via mail.wss.co.uk, which is an ixwebhosting account. | 17:07.08 |
| and it works perfectly for everything except gs-devel | 17:07.31 |
chrisl | Hmm, that should be fine. Do you ever use gmail webmail? Maybe try a test message from there? | 17:07.53 |
Robin_Watts | I *never* use gmail. | 17:08.10 |
chrisl | Except for all your artifex mail..... | 17:08.26 |
Robin_Watts | I consider gmail to be evil, and I don't think anyone should be using it, but that's a discussion we've had before. | 17:08.36 |
| chrisl: All my artifex mail gets bounced to an @wss.co.uk address. The fact that gmail handles the artifex.com address is an unfortunate fact that I have no control over. | 17:09.21 |
chrisl | Robin_Watts: true, I wasn't suggesting you start using gmail directly, just for a test | 17:09.55 |
Robin_Watts | I'm not sure robin.watts at artifex.com has a gmail box set up with it. ISTR that marcosw implemented me as a list or something | 17:10.54 |
| because they didn't have enough boxes at the time and I didn't want one? or something like that. | 17:11.18 |
mvrhel_laptop | bbiaw | 17:12.53 |
chrisl | Robin_Watts: Oh, okay. It's odd that it works fine for the other lists hosted by the same mailman on the same server! | 17:13.53 |
Robin_Watts | It's very odd, yes. | 17:15.09 |
chrisl | Robin_Watts: apparently that error can arise if the mail server thinks your sending to an address with a mail loop, so I wonder if the odd configuration of your artifex address causes that confusion | 17:20.42 |
Robin_Watts | chrisl_away: OK. So I can log into gmail on that account, and I can post from there. how odd. | 17:37.09 |
henrys | rayjj_: you around? | 18:23.51 |
marcosw | henrys: do you have a second for a quick question? | 19:52.02 |
henrys | what's up marcosw? | 19:52.33 |
marcosw | it's about the asian cid fonts that we make available on artifex.com/AsianFonts. just confirming that your understanding is that it's okay for commercial customer to distribute them with Ghostscript. | 19:53.50 |
henrys | that's my understanding, yes. | 19:54.08 |
| bbiab | 19:54.14 |
marcosw | thanks. me too, but wanted to make sure. | 19:54.20 |
| Forward 1 day (to 2013/07/18)>>> | |