http://bugs.ghostscript.com/show_bug.cgi?id=698246
Sebastian Rasmussen <***@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |***@hotmail.com
--- Comment #7 from Sebastian Rasmussen <***@hotmail.com> ---
A few suggestsions:
1.2 License:
Page 2: "you *must* abide by the following terms." --> "you *must* abide by the
terms described by GNU AGPL. These are explained in layman's language below,
but the legal requirements are still those set out in GNU AGPL."
Page 2: "you must license the entirety of that installation under the GNU AGPL"
--> "you must license the3 entirety of that installation under the GNU AGPL or
a compatible license
(https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)."
Page 2: "must be licensed under the GNU AGPL." --> "must be licensed under the
GNU AGPL or a compatible license
(https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)."
Page 2: Perhaps also add a section along the lines of
"Because of Artifex makes MuPDF available under both GNU AGPL and a commercial
license contributing bug fixes or patches to the project requires a signed
Contributors License Agreement (permanent(!) link to artifex.com where the CLA
is available). This is required in order for Artifex to retain the copyright of
the full source code, so as to be able to relicense it under a commercial
license for its customers."
1.3 Dependencies:
Page 3: Mention LCMS2 now that is has been integrated.
Page 3: "OpenType Font shaper built upon freetype, required for e-pub files."
--> "OpenType Font shaper required for e-pub files, handles RTL languages." or
something to that effect
Page 3: Perhaps mention the other J2K image decoding library? And why it might
be better? And also when it is available?
3.4 Multi-threading
Page 9: "multi threaded" --> "multi-threaded"
Page 9: "MuPDF guarantees never to take lock n if that thread already holds
lock m (for n ¿ m )." The upside-down question mark is likely not the character
meant to be here...
Page 9: Perhaps add something to the effect of:
"Each displaylist can safely be used from several different threads as long as
there are safeguards in place to prevent the usages being simultaneous."
3.7 Tuning
Page 11: Why would I want to decode a bigger subarea of an image when only a
smaller one is required? What happens if a decode a smaller subarea? Would
images be correctly decoded but at a lower sample rate?
Page 11: A short explanation of what Mitchell scaling is? What are the trade
offs when using/not using it?
3.8 Summary
Page 13: Maybe add "Display lists can only be used in 1 thread at a time."?
4.1 Overview
Page 14: Describe that it is not ok to call functions that may throw in
fz_always() (or else all the code in fz_always() will not be executed). This
also makes it vital to explain somewhere that fz_free() and fz_drop*() and
pdf_drop*() may not throw exceptions, making them safe to call from
fz_always().
Page 15: "If you do not wish to understand the long and complex reasons behind
this, skip forward to the summary and just follow the rules there." If I do
indeed skip until the Summary, this part nor Summary explains what protecting a
variable by a fz_var() call looks like. I suggest putting an example here and
the cited sentence above after the example..?
Page 15: "fz_try/fz/catch()" has a slash typo. "As stated before fz try/ fz
catch" has a space too much after the slash (this happens on page 16 too, is
this stylistic? If so, why does setjmp/longjmp not have a space after the
slash?)
Page 15: Perhaps put emphasis on that if and only if fz_rethrow() is called
will the exception be propagated to the enclosing block? And conversely
explains that execution will simply continue after fz_catch() unless
fz_rethrow() is called.
Page 16: "Or fz_rethrow if we’re nested." what does this comment mean? Maybe it
is better to explain what happens if you call NULL: "Do not propagate the
exception, silently return NULL instead." I would get it instantly. It might be
better to clearly explain fz_rethrow() in the previous example as I try to
suggest above. :)
Page 16: Maybe explain that the combined house has to keep its own references
to the walls and the roof and that what we drop in fz_always() are the local
references not owned by the house?
Page 16: "this means that any local variables set within the fz_try block can
be 'lost'" --> "this means that any local variables set within the fz_try block
can have their new values 'lost'" or perhaps "this means that any changes to
local variables within the fz_try block can be 'lost'"
Page 16: "By calling fz var(w);" --> "By calling fz var(w) before fz_try()"
Page 16: "The 'loss' of the value occurs because the compiler can postpone
writing the value back into the storage location for the variable (or can
choose to just hold it in a register)." --> "The 'loss' of the value occurs
because the compiler can keep a temporary copy of a value in a register,
postponing writing the value back into the storage location for the variable
(or can choose to optimize the code to always hold the value in a register)."
page 17: longjmp should be bold..?
Page 17: "any functions it call" --> "any functions it calls"
Page 17: "Hence the variable is magically protected." --> "Hence the variable
is guaranteed to have the last value set, regardless of whether longjmp is
called or not."
4.2 Throwing exceptions
Page 18: What are the non-FZ_ERROR_GENERIC values used for? Are there some
values that should only be used by the core library?
4.3 Handling exceptions
Page 18: Explain that fz_caught() should only be inside fz_catch or be called
if and only if fz_catch has been executed (while an exception is still on the
exception stack). Also how does looking at the error code help in retrying the
same code in a different manner? Isn't it better to state that an application
might want to retry executing upon some type of exceptions, while erroring out
on other types..?
Page 18: "convenience function that with rethrow just a particular type.:" -->
"convenience function that will rethrow just for a particular type:" Notice the
removed period.
4.4 Summary
Page 19: "within an fz_try" --> "within a fz_try" as long as we read that as
"within a fitz try", probably several instances of "an fz_"... But if you read
that as "within an EFF ZED try" then of course this comment is no longer valid.
:)
--
You are receiving this mail because:
You are the QA Contact for the bug.