Live data from Hacker News

Embedded PDF viewer in Firefox 81 supports filling forms

support.mozilla.org

381–384 of 384 posts

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#381

I find the built-in PDF reader in Firefox to be bloat. It's OK, it works 95% of the time, but really I want to use a native PDF viewer. Is there a version of Firefox that removes this bloat? Given that Mozilla is very resource constrained, why are they working on features that aren't necessary?

I find it extremely convenient. Also I know a lot of security issues in PDF viewers are effectively solved by running it in the browser's JS sandbox.

Firefox's sandboxing incomplete or nonexistent (e.g. GPU process is not sandboxed on Linux).

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#382
post #378

Earlier quoted context omitted.

A pdf at [0, N] sorts before the one at [0, N+1], by "first valid pdf".

No, both start at 0. Also, [0, infinity] and [0, infinity+1] are the same thing.

https://www.online-python.com/OuZ0thRs6D

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#383
post #378

Earlier quoted context omitted.

No, both start at 0. Also, [0, infinity] and [0, infinity+1] are the same thing.

https://www.online-python.com/OuZ0thRs6D

your example fails to satisfy the invariant. 11 is less than infinity.

you're just pasting random python snippits at me now. It's time to move on.

again, just to summarize: PDF files do not have to be zero aligned, and they do not have to be end aligned. Therefore the answer to the question "what is the first segment of Pi that is a valid PDF file" is trivially (0,infinity). That is a correct statement. The non-greedy (in the regex sense) answer to that question will be different, however.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#384
post #383

Earlier quoted context omitted.

https://www.online-python.com/OuZ0thRs6D

your example fails to satisfy the invariant. 11 is less than infinity. you're just pasting random python snippits at me now. It's time to move on. again, just to summarize: PDF files do not have to be zero aligned, and they do not have to be end aligned. Therefore the answer to the question "what is the first segment of Pi that is a valid PDF file" is trivially (0,infinity). That is a correct statement. The non-greed…

Why is this so hard? If the tuple (0,10) represents the range of a valid pdf, then the next tuple (0,11) is also a valid pdf. Or any after it up to and including (0,infinity).

Note the word "next", implying that (0,10) sorts before (0,11); you even say it yourself "11 is less than infinity". Where I'm from "first" and "less" are related (the first element in a unique sorted list is defined to be less than all other elements). So if there is any valid pdf in pi that can be identified by the range tuple (0,N), then the first valid pdf must occur before N -> infinity. Therefore (0,infinity) can never be the first valid pdf, even though it may be a valid pdf.

Maybe a picture would help:

    Potential pdf file ranges in pi: [(0,0),(0,1),(0,2),(0,3),(0,4),...,(0,N-1),(0,N),(0,N+1),(0,N+2),...,(0,infinity)]
    Is it a valid pdf?                 no    no    no    no    no  (no)  no      yes   yes     yes   (yes) yes
    Which one is first?                                                          ^^^
I thought linking to a python script that shows the order comparison of a tuple (0,N) as less than the tuple (0,N+1) would clearly demonstrate this, but it appears to have failed to communicate that to you. We don't need non-greedy regex rules to do a less than comparison.
Post reply on HN