| | <<<Back 1 day (to 2020/07/30) | Fwd 1 day (to 2020/08/01)>>> | 20200731 |
| apollo13 | Robin_Watts, sebras: Hi, as promised I talked to my colleagues with regard to support contracts. Given your responsiveness on our issues we think that we would benefit from support/licensing mupdf. Do you have any suitable contact address for me that I can pass on to our product owner, so she could contact you outside of this channel? | 09:00.23 |
| kens | apollo13: I think the approved method is to go to the Artifex web site, there's a green button at top right labelled contact sales that then takes you through a very simple couple of steps starting with 'which product'. If you have any problems you can shout at us here and we can contact the relevant person for you. | 09:02.17 |
| | So that'shttp://www.asrtifex.com/contact | 09:02.35 |
| apollo13 | ok, I will pass that on. Thanks | 09:03.44 |
| kens | wonders what Tor's opinion of the highlights for the buttons on that page is, the blue rectangle whose corners go outside the rounded button looks odd to me.... | 09:03.57 |
| Robin_Watts | http://www.artifex.com/contact even (sorry, possibly obvious, but if apollo13 is cutting/pasting into an email, best to get it right) | 09:06.59 |
| kens | Yes, sorry typo there | 09:07.12 |
| apollo13 | no worries, I saw that one | 09:07.19 |
| Robin_Watts | apollo13: Fab, thanks. | 09:07.49 |
| ator | avih: it's non- | 09:15.40 |
| | trivial to do 3-color alpha channel masking of text (as per cleartype) in a general PDF workflow | 09:15.58 |
| | and colored text is going to mess things up real good | 09:16.19 |
| | it really only works for black text on white, or the opposite | 09:16.43 |
| | and if you do get into colored text and want to do it right, you're going to be better off rendering 3x wide and filtering | 09:17.13 |
| | which is the exact same filtering you'd need to do while rendering the text so I don't understand your comment about "filtering is not trivial". | 09:18.32 |
| | I mean, yes, I agree that making a good filter is not easy, and possibly patented, but that fact is not going to change anythinvg. | 09:18.56 |
| | early freetype filtering used a terrible filter (probably to stay well clear of microsoft's patents in the area) | 09:19.24 |
| Robin_Watts | Not to mention the fact that many devices (including all the apple-crap) use pentile screens. | 09:25.42 |
| | so filtering doesn't work sanely. | 09:25.49 |
| sebras | ator: we have a file with an encryption dictionary but the string/stream encryption is /Identity. | 09:57.13 |
| | ator: the reason there is an encryption dictionary is that embedded files are encrypted. | 09:57.33 |
| | ator: pdf_needs_password asks for a password because doc->crypt is non-null. | 09:57.50 |
| | ator: trying to authenticate the default "" password fails though. | 09:58.19 |
| | ator: making pdf_needs_password() always return 0 allows for mupdf to open the file without problems, which matches with the /Identity encryption. | 09:58.47 |
| | ator: pdf_load_embedded_file() does not take /EFF in the encryption dictionary into account. | 09:59.22 |
| ator | sebras: ugh. :( | 10:00.42 |
| sebras | ator: should pdf_needs_password() ask for a password when we open the document, but then not autenticate it until the embedded file is loaded? | 10:00.44 |
| | I can't figure out what we want here. | 10:00.59 |
| ator | shouldn't all passwords work with /Identity encryption? | 10:01.24 |
| | or why does it fail? is the password correct for the sub-file? | 10:01.42 |
| sebras | well, /O and /U are probably related to the embedded file encryption. | 10:01.56 |
| | so "" presumable fails to authenticate because /O and /U match the embedded file password. | 10:02.18 |
| | ator: I don't think there _is_ any embedded file. | 10:05.39 |
| kens | Sense is not a prerequisite for PDF creators :-( | 10:09.49 |
| ator | sebras: you mentioned pdf_load_embedded_file() | 10:12.18 |
| | I'm confused | 10:12.43 |
| kens | ator as far as I can see, the PDF file has a strea, which has an attached CryptFilter. That CryptFilter has /StmF and StrF set to Identity (no decryption) but has /EFF set to StdCF and StdCF AuthEvent is EFOpen. It uses AESV2 with a Lenght of 16. So we should only autoenticate the password when opening an embedded file. However that stream does not contain any embedded files (in fact I don't | 10:31.10 |
| | think random streams can contain embedded files can they ? | 10:31.20 |
| kens | needs to read up on embedded files now.... | 10:31.32 |
| | and indeed there are no /EF entries.... | 10:33.09 |
| | It appears to be the trailer dictionary is a compressed XRef stream. It specifies (as sebras says) that the strings and streams in the file are not encrypted (/Identity) but that any embedded files are encrypted. | 10:38.21 |
| | So the question sebras was askign I think, was where should the password prompt come ? | 10:38.34 |
| | You don't need the password to read and render the PDF file, you only need it to decrypt the embedded files (which are not present!) | 10:38.57 |
| | Ah, sebras was saying that the pdf_load_embedded_file isn't even looking at the /EFF entry in the CryptFilter. So if there were an embedded file, then it woudl not decrypt it. | 10:40.04 |
| | ator ^^ | 10:40.06 |
| | I think GS can ignore hte /EFF stuff since we don't process embedded files. | 10:40.40 |
| ator | kens: right. asking for the password when extracting embedded files would be an awkward change of API and possibly larger restructuring of things, but not impossible. | 10:43.18 |
| kens | I'd guess you would only need it for tools | 10:43.36 |
| | You don't need to read embedded files to render the PDF | 10:43.47 |
| ator | kens: mupdf-gl can save and create embedded files as used by the FileAttachment annotation type | 10:43.57 |
| | but for just rendering, true, we can ignore it | 10:44.18 |
| kens | Oh, well in that case you should probably detect that and ask up-front ? | 10:44.19 |
| ator | kens: yeah, it's just a matter of where we store the password and encryption things | 10:44.35 |
| kens | Fair enough | 10:44.42 |
| ator | if we limit it to embedded files, it could go through those convenience functions that do the filename lookups etc | 10:45.13 |
| kens | defers entirely to ator on MuPDF | 10:45.31 |
| | But I think sebras suggested that the embedded file code wasn't even looking at the /EFF entry in the CryptFilter currently | 10:46.01 |
| | So an encrypted embedded file couldn't be extracted ? | 10:46.19 |
| ator | sebras: in pdf-link.c there's a group of functions (pdf_embedded_file_stream, pdf_load_embedded_file, etc) | 10:46.26 |
| kens | will go back to poking GS with a long pointy stick | 10:46.57 |
| ator | kens: I think each stream in a PDF can use a separate encryption dictionary | 10:46.57 |
| | but can they use separate passwords too? | 10:47.05 |
| kens | And that means each one could have a different password ? | 10:47.09 |
| | Great minds :-) | 10:47.20 |
| ator | I'm not sure, but worst case yeah | 10:47.21 |
| kens | That's never going to fly with GS | 10:47.35 |
| | no way to request a password | 10:47.41 |
| sebras | reads the logs. | 10:48.03 |
| ator | best case: there's only one (a global) password, but it's only required for embedded files | 10:50.42 |
| sebras | ator: not only for the embedded files though. | 10:50.52 |
| ator | in that case we should allow opening the document anyway | 10:50.53 |
| | but we would fail at reading the embedded files with a proper error | 10:51.14 |
| sebras | ator: if you change the security settiys, (is printing allowed etc), then you _also_ need the password to update the hashes (as they include the password _and_ the security settings). | 10:51.28 |
| ator | sebras: and we might need the password to save the file too | 10:51.48 |
| sebras | ator: yes, if I stub pdf_needs_password() to return 0, I woudl expect mupdf to fail to extract the data with a proper error message. | 10:52.06 |
| | ator: is saving a special permission that might require a password? | 10:52.27 |
| ator | when we save the file, we read and write all the streams | 10:52.56 |
| | that means needing to be able to decrypt them | 10:53.01 |
| sebras | ator: ah, yes. of course. | 10:53.20 |
| ator | maybe, just maybe, we can get away with copying the data in the PDF_ENCRYPT_KEEP case | 10:53.56 |
| sebras | ator: so what we _could_ do is to hav pdf_needs_password() return 1 even if the string/streams filter is /Identity because we have determined that /EFF is not. | 10:53.59 |
| ator | sebras: even if StrF/StmF is /Identity, we may need the password because individual streams can have their own crypt filter | 10:54.36 |
| sebras | and then as you said, keep the password around until we encounter an embedded file that needs it (basically when pdf_load_embedded_file() is called). | 10:54.38 |
| | ator: right. | 10:55.03 |
| ator | my PDF crypt knowledge is rusty enought that I don't remember whether the password is per cryptfilter or per document | 10:55.11 |
| sebras | ator: that's great question. I wonder that myself. | 10:55.26 |
| | ator: I guess it comes down to how many /O and /U entries are allowed. | 10:55.41 |
| ator | the pdf 1.6/1.7/whatever version that added those features are just a total spaghetti mess | 10:55.53 |
| sebras | ator: how does one know if a stream has a its own cryptfilter? | 10:57.07 |
| | oh 3.5.4 in pdfref17. | 10:57.42 |
| ator | looks like they only toggle the encryption on/off (and select crypto algorithm) | 10:58.04 |
| sebras | ator: yeah. I read this as that there is only a single password for the entire document. | 10:58.31 |
| ator | pdf-stream.c: pdf_stream_has_crypt scans for it | 10:58.46 |
| | and if true, we open a normal 'crypt' filter for that stream | 10:59.01 |
| | might need to extend the doc->crypt to cover "EFF" as well, and pass that from pdf_load_embedded_file somehow | 11:00.43 |
| sebras | yes. | 11:00.53 |
| | most importantly is that we recognize /Identity and _not_ require a password in that case perhaps? | 11:01.11 |
| ator | sebras: how do you want to handle that case? allow opening it with a blank password but warn that it can't be saved. | 11:01.32 |
| sebras | no, we shouldn't ask for a password at all..? | 11:01.46 |
| ator | sebras: what if a stream uses a crypt filter then? | 11:01.58 |
| | we can't easily come back and ask for a password later | 11:02.14 |
| sebras | yeah, that would be a problem. | 11:02.39 |
| | may pdf_open_raw_filter() should look at doc->crypt and decide if that pdf_open_crypt() should be called? | 11:02.59 |
| | right now it only checks if doc_crypt exists. | 11:03.11 |
| ator | build_filter calls pdf_open_crypt_with_filter in one case where the Crypt is not the default crypt->stmf so it's a definite possibility | 11:03.50 |
| | just because you can read parts of the document without the password, doesn't mean we should not ask for it, IMO | 11:04.10 |
| sebras | ok. | 11:04.20 |
| | the pdf_needs_password() should ask for the password regardless of where it is used. | 11:04.31 |
| | and then we should only take it into account where needed. | 11:04.41 |
| ator | or we could extend it to be not-boolean (NO, WANTS, NEEDS) | 11:04.53 |
| sebras | that resolves the API issue with asking for the password when extracting an embedded file stream. | 11:05.01 |
| ator | sebras: yeah. the thing is we can't trust the /Identity in the StmF to cover all the streams in the file | 11:05.46 |
| | because each stream can override it | 11:05.50 |
| sebras | ator: though a PDF with an embedded file coiuld then not be openend unless you know the password for the embedded file. perhaps there are PDFs where the embedded files should only be extractable by some people (who know the password), and the rest of the document should be accessible to everyone. | 11:06.32 |
| ator | so either we change the password API completely, and come back with a "needs password" exception that has to be handled by the user anywhere | 11:06.40 |
| | or we don't break things and disallow this case | 11:06.53 |
| sebras | yes, I agree. | 11:07.09 |
| | the "needs password" exception is probably what we _should_ do, but I don't know if this restructuring is worth the effort. | 11:07.34 |
| ator | sebras: yeah, I expect that's what they may have been going for, but we can't know that without reading the whole file looking to see that we will never need a stream password | 11:07.36 |
| sebras | right. | 11:08.00 |
| ator | sebras: yeah. the "right" solution will be awkward (but I guess a bit like TRYLATER) | 11:08.01 |
| sebras | yes. | 11:08.10 |
| | TRYPASSWORD | 11:08.22 |
| ator | FZ_ERROR_NEEDS_PASSWORD and then remove the current needs_password/authenticate completely | 11:08.43 |
| | and make everyone handle the exception (ugh) | 11:08.56 |
| sebras | yes. | 11:09.00 |
| ator | will be problematic because you'll get it in the middle of something else and then need to interrupt whatever you were doing for user feedback | 11:09.15 |
| malc_ | good luck with that | 11:09.17 |
| ator | malc_: not even gonna try, if I can help it :) | 11:09.33 |
| sebras | so we add fz_open_accelerated_document_with_stream_with_password()? | 11:09.34 |
| malc_ | ator: :) | 11:09.56 |
| ator | sebras: I think one semi-sensible approach is to return a magic number from needs_password that says "yes I need it but you can try without it" | 11:10.16 |
| | in the case StrF and StmF are /Identity | 11:10.27 |
| malc_ | ator: i found another area where FC660M beats RF2 | 11:10.31 |
| sebras | ator: StrF could be /Identity and /StmF not, right? | 11:10.42 |
| ator | and then toss an exception when we open an encrypted stream | 11:10.45 |
| | sebras: they don't have to be the same, no | 11:10.59 |
| | but we can't even start opening the file if StrF is not identity (and I don't think there's a way to override StrF for an object) | 11:11.24 |
| sebras | ator: cryptfilters can have /AuthEvent set to /DocOpen or /EFOpen. that indicates when authorization should happen (when opening the document or when opening the embedded files). | 11:12.23 |
| | ator: right. | 11:12.41 |
| ator | sebras: oh. that might be a decent way. | 11:13.02 |
| | sebras: I've programmed myself to ignore everything PDF with *Event :) | 11:13.15 |
| | as "useless fluff" | 11:13.20 |
| sebras | ator: that is mostly true. | 11:13.29 |
| ator | so if AuthEvent is set and not DocOpen, and StrF and StmF are Identity, return needs_password 0 | 11:14.39 |
| sebras | ator: so it seems to me that there is only two two choices to ask for the password. | 11:14.50 |
| ator | and add a separate embedded_needs_password | 11:14.57 |
| | that we'll call in the attachment UI | 11:15.07 |
| sebras | ator: what do we do for saving a PDF with an embedded file though? | 11:15.28 |
| | ator: maybe you haven't clicked the embedded file attachment and supplied the password yet. | 11:15.47 |
| | would we call embedded_needs_password() before saving? | 11:16.39 |
| | that would presumably need the embedded file dictionary. | 11:16.57 |
| ator | if save_opts.do_encrypt is PDF_ENCRYPT_KEEP then maybe we can get away without asking | 11:17.07 |
| sebras | oh, because we never need to decrypt it! | 11:17.30 |
| | what if it is not PDF_ENCRYPT_KEEP then? | 11:17.41 |
| ator | then we need to ask the password | 11:18.01 |
| sebras | can we know that before we call pdf_save_document()? | 11:18.18 |
| ator | actually, I think we can only get away with it iff PDF_ECRYPT_KEEP _and_ incrementally saving | 11:18.31 |
| sebras | wait... doesn't the password hash include the /trailer/ID? | 11:18.59 |
| | so if /trailer/ID changes we need to ask for the password again. | 11:19.29 |
| | and if the security settings have changed. | 11:19.42 |
| ator | sebras: you know what, let's just not bother :) | 11:19.42 |
| | ask the password if we need it, question is whether to delay it in the viewers | 11:20.05 |
| | so only ask if opening embedded files or saving a document that has embedded files | 11:20.18 |
| sebras | ator: I say örk about all of this, just örk. | 11:21.05 |
| | do we support changing security permissions for a document? | 11:21.18 |
| ator | unfortunately I'm not sure we can easily detect an embedded file because the FS can point to just about anything | 11:21.23 |
| | sebras: yes. I think so. | 11:22.00 |
| | we can change encryption method and presumably permissions (since we have a 'permissions' filed in pdf_write_options) | 11:22.16 |
| | field | 11:22.21 |
| malc_ | wtf is örk? | 11:23.54 |
| sebras | ator: right, but mupdf-gl does not support setting permissions. | 11:24.30 |
| | malc_: corresponds to English's "ewww". | 11:25.06 |
| malc_ | sebras: oh... tack! you live you learn | 11:25.43 |
| sebras | malc_: varsågod. | 11:25.50 |
| malc_ | å is the letter that makes finns go örk | 11:26.29 |
| sebras | ator: if mupdf-gl allowed changing permissions and we have an embedded file we would need to change the password hash for that cryptfilter even if we have PDF_ENCRYPT_KEEP. | 11:26.32 |
| | I need to pop out for dinner. this seems to require further thought anyway. | 11:27.18 |
| malc_ | hast du one god spissa... that almost exhausts my fuck with gecmanic languages arsenal | 11:28.44 |
| | damn i should have used bra not god... | 11:29.09 |
| | oh well | 11:29.12 |
| ator | sebras: we should probably set/delete the AuthEvent when changing encryption and saving | 11:29.58 |
| sebras | ator: yes. | 11:30.12 |
| | I was hoping that this document would be easily fixed since it was not really encrypted. | 11:30.45 |
| | instead it has unleashed a wealth of issues that need fixing. :) | 11:31.09 |
| avih | ator: yeah, i know it's hard to do well, which is why I didn't agree with Robin_Watts' comment at https://ghostscript.com/pipermail/gs-bugs/2016-June/044643.html . also correct that i don't think anyone does it on pentile display. nevertheless, my points are: 1. many prefer it (and/or some hinting) where applicable. 2. it's applicable for a LOT of people (probably most on desktop/laptop). 3. it's hard, inefficient and of lesser quality to do as "postprocessing" | 11:37.11 |
| | to grayscale output. 4. therefore it would have been nice if mupdf offered some support for it. | 11:37.11 |
| | yes, it's effort, and harder with colors (though freetype2 does handle it well), but it does produce results which many find more legible on screen | 11:38.47 |
| malc_ | avih: what's "pentile display"? | 11:39.12 |
| avih | ator: does mupdf use freetype2? to render glyphs only? or words? or lines? | 11:39.26 |
| | malc_: google is your friend. wikipedia too. | 11:39.42 |
| malc_ | avih: google has no friends, as for wikipedia will try that thanks | 11:40.11 |
| avih | i didn't say you're google's friend... | 11:40.35 |
| | (which you are, btw) | 11:40.56 |
| malc_ | we have mutual disdain for one another | 11:41.12 |
| | and wikipedia has a generic weak reference article nothing gccbugy about it | 11:42.08 |
| avih | https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjZgrT8s_fqAhVNzKQKHdw-DOUQmhMwRXoECAMQAg&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FPenTile_matrix_family&usg=AOvVaw0P7GTUI2ePUv6zAbeUU1_R | 11:42.21 |
| | https://en.wikipedia.org/wiki/PenTile_matrix_family | 11:42.28 |
| Robin_Watts | 2. Anyone with a retina (or 4K) screen will be pentile on a laptop. | 11:42.54 |
| malc_ | thanks | 11:42.56 |
| | and your first attempt is precisely why google blows goats | 11:43.15 |
| Robin_Watts | 3. It's certainly not harder, and it's not lesser quality. | 11:43.21 |
| | malc_: Until about 15 years ago, all screens had their pixels made up of subpixels. | 11:43.49 |
| | So 5 pixels would actually be RGBRGBRGBRGBRGB | 11:44.08 |
| | This was true for CRTs and for LED screens. | 11:44.24 |
| malc_ | Robin_Watts: i only switched from my CRT like 3 or 5 years ago | 11:44.30 |
| Robin_Watts | right. | 11:44.36 |
| | with CRTs it was phosphors. | 11:44.45 |
| | front door. brb. | 11:44.47 |
| avih | Robin_Watts: it's (near enough) impossible to apply hinting as postprocessing | 11:48.09 |
| | and yes, it's not applicable everywhere, but it applicable for many many users | 11:48.54 |
| | and there's a reason that by default windows and osx enable subpixel aa by default - people prefer it. | 11:50.39 |
| kens | No, people just can't turn it off | 11:50.56 |
| | Personally I've always done everything I can to turn off ClearType, its an abomination. I *hate* my text going blurry and colour fringed | 11:51.25 |
| | There were plenty of complaints when it was introduced, Microsoft simply applied the usual Microsoft policy of ignoring them | 11:51.49 |
| | Now everyone thinks its normal | 11:52.03 |
| avih | it's very easy to turn if off, and obviously not everyone prefers it, but most do IMO | 11:52.18 |
| kens | You can no longer turn off ClearType entierly in Windows 10 | 11:52.36 |
| malc_ | avih: i think cleartype is an example of mass psychosis | 11:52.37 |
| avih | cleartype is very good. personally i liked it from the first time i saw it. | 11:53.07 |
| kens | Congratulation, personally I detested it from day one and have never changed my opinion | 11:53.28 |
| malc_ | https://github.com/moosotc/snippets/blob/master/.config/fontconfig/gen.sh | 11:53.29 |
| kens | If you are happy with it, great, but I would like a way to turn it *off* | 11:53.44 |
| avih | it's subjective obviously, but freetype2 does a very good job at it these days - for those who do prefer subpixel aa | 11:53.45 |
| | kens: you seriously can't turn it off? | 11:54.21 |
| kens | Not in Windows 10, you can adjust the settigns, you cannot remove it entirely. | 11:54.37 |
| | The same may have been true of Windows 8, I was lucky enough to miss that partocular catastrophe altogether | 11:55.03 |
| malc_ | kens: i was under impression that DirectWrite was cleartype incompatible | 11:55.22 |
| | apparently i was wrong | 11:55.27 |
| kens | Hmm, I wouldn't know. Its possible that API bypasses it. | 11:55.59 |
| | I mean obviously you can turn your text into an image, and then it doesn't happen any more | 11:56.13 |
| | "Text in DirectWrite is rendered using Microsoft ClearType" | 11:57.27 |
| | From: | 11:57.39 |
| | https://docs.microsoft.com/en-us/windows/win32/directwrite/introducing-directwrite | 11:57.39 |
| malc_ | anywho never used rgb rendering and under ators influence turned off hinting too - happy camper | 11:57.43 |
| avih | kens: i'm not asserting that you should like it. i'm saying there are definitely those who like it, and there a lot of places where it's applicable. please forget microsoft. | 11:57.45 |
| Robin_Watts | malc_: high density screens work on something like: BRGRB repeated. | 11:58.13 |
| kens | You say 'many many people like it' but I don't see any figures for that. | 11:58.18 |
| | I see a few people hwho like it, and an awful lot of people saying nothing | 11:58.30 |
| Robin_Watts | so the G (broadly, the brightness) is shared between neighbouring pixels. | 11:58.45 |
| avih | because most people like it and get it, they won't rave about how nice it is. and same for those who don't like it - unfortunately for them someone turned it on by default, so you do hear them cry out | 11:59.23 |
| malc_ | kens: thanks for the link, it has a nice note that grayscale is to be preferred though | 11:59.53 |
| kens | That's a perspective, my take on it, is most people dont notice, or have been exposed to is to long they don't realise thre's an alternatvie and think text is *supposed* to be rendered with funny coloured fringes | 12:00.00 |
| avih | IMHO the mere fact that most OSs enable by default is a sign that according to their research most do prefer it | 12:00.06 |
| Robin_Watts | To light up a single pixel as white, on a normal screen you light up a triple of RGB. | 12:00.08 |
| | so you might say rgbrgbrgbRGBrgbrgb (where caps are on and little are off). | 12:00.27 |
| kens | avih I think its a clear sign they've been seduced by the Dark Side | 12:00.32 |
| | Not that my opinion matters, since I don't work on MuPDF | 12:00.49 |
| Robin_Watts | Equivalently you can light a white pixel a smidge further to the right by lighting: rgbrgbrgbrGBRgbrgb | 12:01.09 |
| | and for individual pixels it's REALLY hard to tell the difference. | 12:01.29 |
| malc_ | Robin_Watts: ~190DPI here, is it \hight | 12:01.36 |
| | *high | 12:01.42 |
| | ? | 12:01.45 |
| Robin_Watts | malc_: I'd expect that to be a pentile screen, yes. | 12:02.05 |
| avih | kens: so gimme your rough estimation: of whose who do care, how many prefer with subpixel aa and how don't? | 12:02.09 |
| | how many* don't | 12:02.22 |
| kens | avih I have no idea. My guess would be that the vast majority either do not care or are not even aware that there is an alternative. | 12:02.44 |
| | I don't pretend to have any evidence. | 12:02.53 |
| Robin_Watts | BUT when you have different scanlines adjacent where different subpixels are lit up, you can spot the differences slightly as tinges on the fringes. (sorry). | 12:03.09 |
| malc_ | avih: here right now there are 3 people who do not like RGB hacks | 12:03.18 |
| avih | and you're not willing to look at the fact that windows and osx enable it by default. | 12:03.21 |
| | and you're not going to make a research | 12:03.32 |
| | so, your bottom line is that no one likes it, right? | 12:03.40 |
| Robin_Watts | The fact is that it WILL look different to different peoples eyes, on different monitors, in different lights etc. | 12:03.41 |
| kens | It feels to me like the same kind of exercise as OS UI design. "We think this is a good idea, we love it, if you don't love it there is something wrong with you, so we're going to make it the only way to work. After all it is the right way to work" | 12:03.45 |
| Robin_Watts | So it's a matter of personal taste. | 12:03.59 |
| avih | Robin_Watts: absolutely, it's very subjective. i never said otherwise. some definitely prefer gray. | 12:04.12 |
| Robin_Watts | Some people swear by it, some people swear at it. | 12:04.18 |
| kens | avih I have no way to conduct research. But *I* never claimed any numbers. In the nicest possible way you said 'many many people like it' without presenting any evidence, rather like a certain US president | 12:04.41 |
| malc_ | you can scale and rotate gray picture, you cannot do the same with subpixeled one | 12:04.46 |
| avih | kens: so you think osx and windows shove it down their users throats because their design teams thought it's better for the users? you don't think they conducted studies? | 12:05.03 |
| malc_ | so there is at least one criterion where grey is objectively 'better' | 12:05.15 |
| kens | On the whole, no | 12:05.16 |
| Robin_Watts | Now, I coded Picsel's implementation of this years ago. | 12:05.31 |
| avih | Robin_Watts: does mupdf use freetype? | 12:05.48 |
| kens | Someone thought it was a great idea, and in MS case they could patent it (always attractive to a corporate) | 12:05.49 |
| avih | kens: do you actually think they would have kept it enabled by default even when it costs them nothing to disable it and most users would have preferred it disabled? | 12:06.36 |
| Robin_Watts | And there are unquestionably devices on which it DOES work really well. For those I suspect that a majority of people would like it. There are devices on which it does not work well, and a majority of people would hate it. | 12:06.36 |
| kens | avih have you ever used Windows 8 ? | 12:06.48 |
| avih | yes | 12:06.54 |
| | kens: yes or no please | 12:07.02 |
| kens | That was something which was just awful on the desktop | 12:07.06 |
| avih | i happened to like it quite a lot, but it's completely off topic | 12:07.21 |
| kens | avih it does cost them to keep the option. Both routes for rendering need to be maintained | 12:07.28 |
| Robin_Watts | windows is MUCH less "we're doing it this way" than MacOS is. Windows tends to give people a choice. MacOS imposes its will. | 12:07.35 |
| | avih: MuPDF does use freetype. | 12:07.47 |
| | But that doesn't help. | 12:07.51 |
| avih | only for glyphs? or also for words? | 12:08.04 |
| Robin_Watts | because freetype doesn't know about PDF blending (as, clearly you don't, or you'd not be suggesting this :) ) | 12:08.19 |
| avih | correct, i know nothing about pdf rendering | 12:08.35 |
| Robin_Watts | To do this generally with PDF blending, you'd need to do it at the end, NOT at the glyph rendering stage. | 12:09.06 |
| | hence, speaking personally, I have no interest in coding it within mupdf. It's enough for me to know that people can use mupdf to implement it if they want. | 12:10.37 |
| malc_ | avih: fx engine powering pdf stuff in chrome always renders with subpixel rgba. the result is okay most of the time, but then there are times when it isn't and color bleeds like there's no tomorrow and you can do nothing about it | 12:10.44 |
| Robin_Watts | Right, I have to go get lunch and take some blinds down... | 12:13.55 |
| avih | Robin_Watts: yes, it's hard, obviously. i never said it would be easy to support. but i think you should at least acknowledge it's very useful in many cases (combinations of user/content) | 12:14.15 |
| | with blending i'm assuming text over images, which is indeed hard, nevertheless, i'd think most pdf pages out there are pure black text on pure white background | 12:15.23 |
| | (and probably times new roman) | 12:15.55 |
| malc_ | your thinking is wrong | 12:16.33 |
| avih | at least i'm thinking | 12:17.23 |
| malc_ | is that you René? | 12:18.56 |
| avih | i don't know what is rene | 12:19.08 |
| malc_ | given name of René Decartes | 12:19.42 |
| | who used his thinking as a basis for his philosophy | 12:20.12 |
| | cogito ergo sum and all that | 12:20.23 |
| kens | I drink therefore I am | 12:20.36 |
| avih | no, it was me suggesting i'm not interested in statements without some arguments behind them | 12:20.39 |
| malc_ | we have a scott in da house! | 12:20.51 |
| kens | The Philospopher's Song | 12:21.07 |
| avih | anyway, my point is that i think it would be useful to many users if you could support some hinting and/or subpixel antialiasing. | 12:21.51 |
| malc_ | avih: i have provided you with examples, where CT falls way short, you have chosen to ignore them, okay | 12:22.09 |
| avih | not enabled by default of course, but still support where users prefer it. | 12:22.13 |
| kens | I think its fair to say you have presented your point. Its up to the MuPDF developers whether to do anything abou t it (which doesn't include me) | 12:22.41 |
| avih | malc_: i don't care about CT. i'm talking about freetypoe2. | 12:22.42 |
| malc_ | avih: okay rgb rendering in FT2 is just as broken | 12:23.04 |
| | conceptually | 12:23.07 |
| kens | I'd suggest we leave the topic now, I htink its about done to death | 12:23.09 |
| malc_ | seconded | 12:23.20 |
| avih | it's you two continuing it... | 12:23.42 |
| malc_ | no we are not! | 12:24.05 |
| | mommy this boy over there is mean to me! | 12:24.13 |
| ator | avih: hinting is an orthogonal issue to cleartype color filtering (and we do turn it on for non-AA'd rendering modes) | 13:00.11 |
| | if you want cleartype color filtering, it *has* to happen as a post-process due to the intricacies of PDF blending. we don't *know* when rendering black text on a white background, that it's actually going to end up as black text on a white background. | 13:01.03 |
| | so adding a hack to that case won't work | 13:01.15 |
| | take the exact same math you use to filter your cleartype fonts, just apply it to the full 3x wide image and you're done | 13:02.05 |
| | it's not harder, and it's not not lesser quality, there I'm just going to have to disagree with you. | 13:02.41 |
| malc_ | ator: he left a while ago | 13:02.55 |
| ator | oh. | 13:03.10 |
| malc_ | ator: i just found out that xdpyinfo lies through its teeth to make this 4k screen in front of me appear to be 96DPI... scratching my head how to get the panel dimensions in MM | 13:06.09 |
| Robin_Watts | malc_: ruler? | 13:53.30 |
| malc_ | Robin_Watts: that too, https://www.displayspecifications.com/en/model/f72116de gives correct numbers | 13:54.07 |
| | and i was off DPI on this panel is 160ish not 190ish | 13:54.34 |
| Robin_Watts | If it's a 4K panel, it'll be pentile, AIUI. | 13:54.51 |
| malc_ | it is 4k | 13:55.00 |
| | i have an usb microscope and can investigate... yay technology!! | 13:55.25 |
| | Robin_Watts: https://www.boblycat.org/~malc/scratch/mag.jpg is the best i can obtain currently | 15:12.37 |
| Robin_Watts | actually, I take it back. maybe not all 4K ones are pentile. It depends on the dpi. | 15:26.07 |
| | My laptop screen is 1920x1080 in a 13" laptop chassis, so that's "hires", but not "retina". | 15:26.33 |
| | I suspect 4k in a 27" would be similar, so also not pentile. | 15:35.54 |
| | 4K in a laptop chassis will be though, as will the 2k screen on my phone. | 15:36.12 |
| malc_ | it is a 27in 4k | 15:36.59 |
| | 163PPI | 15:37.27 |
| Robin_Watts | http://ghostscript.com/~robin/phone.png | 15:41.22 |
| | THat's using my usb microscope to look at a black/white edge on my phone. | 15:41.49 |
| | So there are 2 green subpixels for every red or blue one. | 15:43.34 |
| malc_ | Robin_Watts: cool.. will try to see if i can increase the magnification fator with my microscope | 15:45.13 |
| paulgardiner | I have an old camera with really good macro. I'll take a picture of one of my 4K monitors once I've charged the camera's battery. | 16:18.15 |
| malc_ | paulgardiner: got a model number? | 16:37.45 |
| paulgardiner | malc_ LG 27UK650 | 17:56.44 |
| | Doesn't look like pentile: http://download.glidos.net/DSC01850.JPG | 18:56.47 |
| malc_ | yeah... that's definitely french pattern | 18:57.13 |
| | julia | 18:57.16 |
| | of which benoit is but a special case | 18:57.46 |
| sebras | I don't know what my screen is and I don't have any reasonable macro lens. | 19:15.57 |
| | <<<Back 1 day (to 2020/07/30) | Forward 1 day (to 2020/08/01)>>> | |
Log of #mupdf at irc.freenode.net.
