| | <<<Back 1 day (to 2016/11/04) | 20161105 |
| sebras | yey, conflicts with half of my jpx patches. and more importantly, I have no idea if any of my patches mess up the latest series of 32 vs 64 bit fixes again. :-/ | 05:41.48 |
| | staying on a branch for too long is never fun. | 05:42.07 |
| | hm... I wonder if -Wsign-conversion is the corresponding gcc-option. | 06:42.22 |
| bartzy | Hi there | 14:41.46 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 14:41.46 |
| bartzy | Iâm looking for a way to specify, in a pdf, that a given object (path) will have some name/reference, that I can later, when parsing the PDF (and before rendering it), can change that objectâs color, gradient etc | 14:42.25 |
| | I can use whatever possible, Illustrator, Acrobat DC, ghostscript or whatever | 14:42.43 |
| | a GUI like Illustrator, to choose a path object and then somehow âtagâ it would be best, since these are sometimes extremely complicated drawings | 14:43.17 |
| Robin_Watts | bartzy: PDF contains a mechanism for 'marked' content. | 14:59.49 |
| | That would be one way of doing it within the PDF format. | 15:00.35 |
| | To suddenly and magically extend existing apps to being able to manipulate that stuff? That sounds like a tall order. | 15:01.12 |
| bartzy | Robin_Watts: Any apps support creating marked content though? | 15:18.49 |
| Robin_Watts | Illustrator uses it for its own purposes. | 15:19.14 |
| bartzy | I just need a way to say : path a, b, c are marked content called âX" | 15:19.28 |
| | yeah but can I tap into that somehow? | 15:19.33 |
| Robin_Watts | That's pretty much exactly what marked content does. | 15:19.52 |
| bartzy | basically what I want to achieve is having a vector graphic, and allow users to change colors | 15:20.05 |
| Robin_Watts | I don't claim to understand exactly how Illustrator uses it. | 15:20.22 |
| bartzy | so in my renderer, Iâd be able to change the colors for these 3 paths | 15:20.24 |
| | but is there any parser/viewer that is more âadvancedâ than acrobat DC and its likes | 15:20.46 |
| Robin_Watts | bartzy: MuPDF contains hooks that would allow you to do that kind of thing. | 15:21.06 |
| bartzy | acrobat DC seems like it thinks that a vector graphics with paths is just an âimageâ. | 15:21.14 |
| Robin_Watts | You understand the basic structure of PDF files, right? | 15:21.37 |
| | The page content is sent as a stream (or several streams) of "operators" | 15:22.03 |
| | stuff like: 1 0 0 rg 0 0 m 100 100 l 100 200 l f.... etc | 15:22.22 |
| | In that example 1 0 0 rg sets the color to red | 15:22.46 |
| | 0 0 m moves to 0 0 | 15:22.51 |
| bartzy | I started reading the spec only today, so I understand it a little⦠It looks very complicated | 15:23.03 |
| Robin_Watts | 100 100 l adds a line to 100 100 | 15:23.07 |
| | 100 200 l adds a line to 100 200 | 15:23.16 |
| | f fills that path | 15:23.23 |
| | and so on. | 15:23.25 |
| bartzy | so basically thereâs not differentiation between the color and the path? Only the location differentiates them? | 15:23.32 |
| | and itâs really textual like that? or binary | 15:23.46 |
| Robin_Watts | bartzy: The 'current' fill color is set to red. then any fills done after that point are that colour. | 15:24.17 |
| | yes, it's really textual like that (though the whole stream might be deflated, so might appear binary) | 15:24.34 |
| | What marked content does is to let you do things like: | 15:24.57 |
| | /Foo BMC 1 0 0 rg 0 0 m 100 100 l 100 200 l f EMC | 15:25.33 |
| | That says "The stuff between BMC and EMC is labelled with the name "Foo" | 15:26.01 |
| | So, you can identify parts of the stream that correspond to particular objects. | 15:26.48 |
| | The graphics state (i.e. the current colour, the current line widths etc) carries on as before though, so you would have to be a bit careful about tweaking it, but it could be done. | 15:27.29 |
| bartzy | and then I can go directly to that object marked Foo? | 15:27.52 |
| | or I need to sequentually get there? | 15:28.07 |
| Robin_Watts | Now, MuPDF allows you to intercept the page interpretation at the operator level. | 15:28.10 |
| bartzy | When you say MuPDF you mean the C library? | 15:28.24 |
| Robin_Watts | Normally to render a page you say "run this page" and that runs through the operators in that pages stream, and turns them into calls to a graphics object level device ("fill this path in this colour", "plot this image", "put this text here" etc). | 15:29.14 |
| | Yes, MuPDF *is* the C library. The example viewers are just incidental :) | 15:29.33 |
| bartzy | Can CoreGraphics do that as well? | 15:29.48 |
| Robin_Watts | nafc, sorry. | 15:29.55 |
| bartzy | change objectâs state | 15:30.00 |
| | :D | 15:30.22 |
| | it seems like it would be much easier to edit in SVg | 15:30.29 |
| | SVG* | 15:30.31 |
| Robin_Watts | MuPDF lets you intercept the operators as they are interpretted. | 15:30.44 |
| | interpreted. | 15:30.48 |
| bartzy | but in iOS (which is what I develop on), CoreGraphics provides a great rendering API for PDFs | 15:30.51 |
| Robin_Watts | and you can either pass them on, or you can modify them etc. | 15:31.06 |
| bartzy | why do I need to take care with the graphics state? | 15:31.22 |
| Robin_Watts | so you could have some code that automatically removed all text from a page by swallowing the text operators. | 15:31.34 |
| bartzy | Because after changing it I need to change it back to what it was befoer? | 15:31.35 |
| Robin_Watts | In your case you can spot the BDC/EMC to know when you are going into your special marked regions, and make changes. | 15:32.04 |
| bartzy | can I mark everything? | 15:32.28 |
| | I mean, can I have some metadata that says âThis is master color 1" | 15:32.50 |
| Robin_Watts | bartzy: Yes, exactly. Imagine that I have: "SET COLOR=RED" "DEFINE A PATH" "FILL THAT PATH" "DEFINE A PATH" "FILL THAT PATH. | 15:32.55 |
| | then imagine that you mark it so it's: | 15:33.07 |
| | "/Color1 BMC" "DEFINE A PATH" "FILL A PATH" "EMC" "DEFINE A PATH" "FILL THAT PATH" | 15:33.39 |
| | ass. let me try that again. | 15:33.56 |
| | then imagine that you mark it so it's: | 15:34.00 |
| bartzy | yeah I understand | 15:34.11 |
| Robin_Watts | "/Color1 BMC" "SET COLOR RED" "DEFINE A PATH" "FILL A PATH" "EMC" "DEFINE A PATH" "FILL THAT PATH" | 15:34.12 |
| bartzy | the 2nd path, after EMC, implicitly thinks that the graphic state is something while I just changed it to somethign else | 15:34.36 |
| Robin_Watts | If you change the "SET COLOR RED" to be "SET COLOR BLUE" you need to be careful as you... yeah. | 15:34.44 |
| | So it's perfectly possible to do the kind of thing you want to. | 15:35.06 |
| bartzy | basically I want to have a master color, in metadata, which I set beforehand (while designing the vector graphic). | 15:35.19 |
| Robin_Watts | PDF files will allow you to set any kind of extra information in them you require. | 15:35.39 |
| bartzy | Then, to âmarkâ paths in the document itself, which would be dertivatives of that master. | 15:36.06 |
| | derivatives* | 15:36.06 |
| Robin_Watts | The PDF viewers won't understand it, but PDF manipulators can. | 15:36.12 |
| bartzy | yeah, it just seems that authoring that file would be extremely hard | 15:36.16 |
| Robin_Watts | bartzy: It would not be trivial, no. | 15:36.25 |
| bartzy | I mean, what is the flow I tell my designer to go through | 15:36.30 |
| | with SVG I can tell them to use Illustrator graphic styles | 15:36.39 |
| | (that maps to CSS classes) | 15:36.45 |
| | or, to tell them just to edit the SVG text direclty | 15:37.00 |
| | with PDF, I didnât find any authoring tool that allows that | 15:37.05 |
| Robin_Watts | AIUI, the native file format used by illustrator is PDF. | 15:37.23 |
| bartzy | .ai is a wrapper for pdf? | 15:37.38 |
| | cool | 15:37.39 |
| | I was sure that Acrobat DC Pro would allow all sorts of stuff like that, but it doesnât : | 15:37.44 |
| Robin_Watts | It uses extra metadata to store illustrator specific information in a file. | 15:37.57 |
| | a .ai file *is* a .pdf file, I believe. | 15:38.12 |
| bartzy | so an .ai file IS a pdf file? | 15:38.13 |
| | lol | 15:38.16 |
| | thatâs pretty cool actually | 15:38.23 |
| Robin_Watts | So, you may find that illustrator does what you want already. | 15:38.37 |
| bartzy | how can I check that | 15:40.02 |
| | is there a nice command line tool to inspect PDFs or something | 15:40.10 |
| | instead of tring to write a (lame) MuPDF client | 15:40.28 |
| | trying* | 15:40.31 |
| Robin_Watts | bartzy: How can you check illustrators capabilities? By using illustrator. | 15:46.29 |
| | If you want to poke around inside PDFs, then I recommend using mutool, part of MuPDF. | 15:46.59 |
| | mutool clean -difgggg in.pdf out.pdf | 15:47.08 |
| | That will convert in.pdf into a much more human readable out.pdf | 15:47.23 |
| | Actually, you might want to just use: | 15:47.37 |
| | mutool clean -dif in.pdf out.pdf | 15:47.44 |
| | to make sure we don't drop anything seemingly unused. | 15:47.55 |
| sebras | Robin_Watts: you around? | 16:33.23 |
| | Robin_Watts: I have been looking at what to do about the types in load-jpx.c, but I'm confused. | 16:34.04 |
| Robin_Watts | sebras: I am. | 16:34.34 |
| sebras | Robin_Watts: I've been thinking that maybe the width/height/etc in fz_jpxd_s shouldn't be JP2_Property_Values at all. | 16:35.37 |
| Robin_Watts | ok... | 16:35.53 |
| sebras | Robin_Watts: maybe they should simply be ints and I should be validating the values extracted from the luratech library before assigning the jpxd..? | 16:36.03 |
| Robin_Watts | sebras: I did the simplest thing I could to shut up the warnings. | 16:36.23 |
| | possibly. | 16:36.26 |
| sebras | Robin_Watts: I also noticed that JP2_Property_Value might be 32 or 64 bit depending on the system. | 16:36.28 |
| Robin_Watts | indeed. | 16:36.40 |
| sebras | Robin_Watts: I wonder why that is becuase really the underlying type in the file has the same width regardless. :) | 16:37.03 |
| Robin_Watts | sebras: Could you review: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=4ccd0b5268d94668297479da8d7ad5566c8d14f6 please? | 16:37.24 |
| | sebras: Ah, well, if you know that... | 16:37.40 |
| sebras | I guess that last part if more of a complaint about the decoder library's decision. ;) | 16:38.01 |
| | not something I can do anything about. | 16:38.08 |
| Robin_Watts | sebras: If you know that, then it seems reasonable to use the 'proper' types, and to cast away from JP2_Property_Value. | 16:39.11 |
| | cos you know that's safe. | 16:39.17 |
| sebras | Robin_Watts: I'm thinking that this would create even fewer casts as the only point where a value is cast is after its range has been validated. | 16:40.20 |
| | Robin_Watts: regarding you patch. so basically if rawsize < 4 there is a problem? | 16:40.38 |
| Robin_Watts | while (i >= 0) is a dumb thing to test when i is unsigned. | 16:40.57 |
| | in the case I saw the problem, rawsize was 16. | 16:41.08 |
| | so i == 16, (so run the loop), i == 12 (run the loop), i == 8 (run the loop), i ==4 (run the loop), i == 0 (run the loop), i == 0xFFFFFFC (run the loop), .... ad infinitum. | 16:41.56 |
| sebras | Robin_Watts: LGTM. | 16:46.32 |
| | Robin_Watts: I was a bit puzzled at first as to why there was no loop for uint16. | 16:46.56 |
| Robin_Watts | Thanks. | 16:51.11 |
| sebras | Robin_Watts: also I tried to make pixmap->{x,y,width,height} unsigned and compile and I didn't see too many issues with that. | 16:52.55 |
| | but then again my compiler seems not to be really trustworthy since msvc discovered so many issues. :-/ | 16:53.17 |
| Robin_Watts | woooah. | 16:55.30 |
| | x and y can't be unsigned. | 16:55.37 |
| | x and y need to be signed because you can easily have negative values in there. | 16:56.03 |
| | width and height should be signed though, except I fear that breeds signed/unsigned madness everywhere when we start comparing pixmaps for overlap etc. | 16:56.42 |
| sebras | Robin_Watts: why is stride ptrdiff_t and not unsigned? | 16:57.24 |
| | Robin_Watts: ok, x,y might be reasonable. | 16:57.45 |
| Robin_Watts | sebras: most sane pixmap formats are downwards. | 16:57.50 |
| | some however give raster lines upwards. | 16:57.59 |
| | like bmp. | 16:58.03 |
| sebras | Robin_Watts: but the fact that I was able to compile using unsigned after changing the code for 3min is surprising. | 16:58.11 |
| Robin_Watts | so to cope with that, we allow stride to be any negative value. | 16:58.29 |
| sebras | Robin_Watts: the bmp decoder doesn't utilize this though (as I wasn't aware that pixmap supported this) | 16:59.18 |
| | Robin_Watts: are any formats using it? | 16:59.31 |
| malc_ | sebras: https://groups.google.com/forum/?_escaped_fragment_=msg/fa.caml/Pp-TL51k3jU/Z6Nm0_QE0kgJ#!msg/fa.caml/Pp-TL51k3jU/Z6Nm0_QE0kgJ | 16:59.33 |
| Robin_Watts | ptrdiff_t is the correct type because stride is strictly defined as "the difference between the pointer to the start of the storage for a pixel and the pointer to the start of the storage for the pixel below it. | 16:59.40 |
| | sebras: It's not for formats to use. | 16:59.52 |
| | Suppose I am implementing an app, and I want to get data output into a particular block of my own memory. | 17:00.25 |
| | I can set up a pixmap header to point to *my* block. | 17:00.38 |
| | We use this to get pixmaps that point to android bitmaps etc. | 17:00.56 |
| | ptrdiff_t is the right type to use. | 17:01.07 |
| sebras | and my block is bottom up..? | 17:01.25 |
| Robin_Watts | sebras: this scheme allows for the possibility that my block might be bottom up, yes. | 17:02.05 |
| sebras | Robin_Watts: ok, if that's the case then fz_pixmap_stride() has the wrong return type. | 17:02.36 |
| | as I understand it. | 17:02.41 |
| Robin_Watts | Yes. | 17:03.08 |
| sebras | Robin_Watts: and e.g. fz_premultiply_pixmap() shouldn't declare int stride but ptrdiff_t stride. | 17:03.39 |
| Robin_Watts | Yup. | 17:04.15 |
| sebras | and in the same function we do s += pix->n; | 17:04.29 |
| | what type should pixmap->n have? | 17:04.37 |
| | I'm not really arguing one way or the other, I just want to understand this so I do it correct. :) | 17:05.28 |
| | at least next time. | 17:05.31 |
| Robin_Watts | strictly speaking pixmap->n can never sensibly be negative. | 17:05.45 |
| | hence unsigned int seems reasonable. | 17:05.55 |
| sebras | Robin_Watts: true, | 17:06.27 |
| Robin_Watts | but then pixmap->n can never be greater than 256 (in our current code), so it could equally be unsigned char. | 17:06.29 |
| | but int covers all the possible values safely. | 17:06.44 |
| | so I am unoffended by int. | 17:06.59 |
| sebras | Robin_Watts: though there is a semantic difference between the int stride and the pix->stride in fz_premultiply_pixmap(). | 17:09.31 |
| | actually int stride appears to just be the padding per each scanline. | 17:09.51 |
| Robin_Watts | sebras: Yes, but strictly speaking it's still a ptrdiff_t. | 17:10.21 |
| | (I make no claims to have all the answers, nor even than there are single correct answers in all cases) | 17:10.48 |
| sebras | Robin_Watts: the reason I'm asking is that if I do change the types in fz_jpxd I might as well change them to the same types we will later on use inside the pixmap | 17:11.39 |
| | Robin_Watts: on an unrelated note -- how are the if-else-blocks supposed to chanin together in fz_paint_affine_near()? | 17:12.07 |
| | Robin_Watts: I'm thinking they are supposed to chain together according to the indentation, but I'm not convinced that the compiler will do that correct. | 17:12.33 |
| | at least I get a gcc-6 warning on line 2177 and 2220 about indentation and guarding. | 17:12.52 |
| Robin_Watts | If the supplied braces are not enough to quash warnings, please feel free to add more. The indentation shows the intention. | 17:13.45 |
| sebras | Robin_Watts: hm, so why does e.g. fz_new_pixmap_with_data() take stride as an int? surely that should be ptrdiff_t too..? | 17:17.12 |
| Robin_Watts | cos it's wrong? | 17:17.47 |
| | we used to use 'int' for everything. Worrying about 64bit stuff is something new for us :/ | 17:18.11 |
| sebras | Robin_Watts: right. | 17:18.20 |
| | this means that offsets in tiff_paste_subsampled_tile() ought to have been ptrdiff_t too. | 17:53.17 |
| | and I'm guessing that I shouldn't be doing dst[*offset]. | 17:54.07 |
| | this is all slightly confusing at this point. | 17:54.16 |
| bartzy | Robin_Watts: Thanks for earlier. Still around? | 22:29.10 |
| Robin_Watts | mmm | 22:32.11 |
| bartzy | Illustrator seems like a mess | 22:46.21 |
| | it has an object in the PDF somewhere, that points to other âprivateâ objects | 22:46.33 |
| | where they have all sorts of data | 22:46.37 |
| | including layer names, and graphic styles | 22:46.41 |
| | but these are not in the layerâs PDf object itself | 22:46.52 |
| | so thereâs no connection :| | 22:47.10 |
| | at least a public, by the spec connection.. as far as I can see | 22:47.20 |
| Robin_Watts | yeah. It doesn't surprise me that it's hairy and undocumented. | 22:47.29 |
| | Certainly the 'extra' information within a .ai file is not documented within the spec. | 22:47.56 |
| bartzy | yeah but I thought that perhaps there would be a way to tell illustrator âmark that content with X" | 22:50.53 |
| | BMC and EMC are what I should look for after doing that mutool clean thing? | 22:51.15 |
| | because I canât find one occurence, which is weird since I read that illustrator does mark some things (and I wanted to know what) | 22:51.32 |
| Robin_Watts | There is also BDC to look for | 22:57.44 |
| bartzy | which is ? | 23:02.10 |
| | I found one BDC :) | 23:02.26 |
| | Forward 1 day (to 2016/11/06)>>> | |
Log of #ghostscript at irc.freenode.net.