(In reply to Andre Guerreiro from comment #76)
> Created attachment 118745 [details] [review]
> Incremental hashing + large file support
>
> With this patch I've implemented the incremental hashing plus the large file
> support.
>
> This is still untested with files larger than 2GB but is
(In reply to Adrian Johnson from comment #78)
> I agree that the two calls to doGetChars and updateHash should be merged but
> I don't think a for loop is the best way to process loops where the
> increment is not exactly the same on each iteration. Maybe something like
> this:
>
> void
(In reply to Adrian Johnson from comment #78)
> I agree that the two calls to doGetChars and updateHash should be merged but
> I don't think a for loop is the best way to process loops where the
> increment is not exactly the same on each iteration. Maybe something like
> this:
>
> void
(In reply to Andre Guerreiro from comment #76)
> Created attachment 118745 [details] [review]
> Incremental hashing + large file support
>
> With this patch I've implemented the incremental hashing plus the large file
> support.
>
> This is still untested with files larger than 2GB but is
I am not sure if I am just missing where this is verified earlier, but
isn't
unsigned int signed_data_len = r2.getInt()+r4.getInt();
unsigned char *to_check = (unsigned char *)gmalloc(signed_data_len);
//Read the 2 slices of data that are signed
doc->getBaseStream()->setPos(0);
I am not sure if I am just missing where this is verified earlier, but
isn't
unsigned int signed_data_len = r2.getInt()+r4.getInt();
unsigned char *to_check = (unsigned char *)gmalloc(signed_data_len);
//Read the 2 slices of data that are signed
doc->getBaseStream()->setPos(0);
Hello,
I am the current maintainer of qpdfview. Since you updated your
distribution, I suppose you also updated your version of qpdfview? Or do
you use an external PPA like [1]?
In any case, if you are now running something higher than version 0.4,
could you try opening a DjVu or PostScript
Marking this incomplete since we are still missing feedback on the
possible solution.
** Changed in: qpdfview
Status: In Progress = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hello again,
could you try the dailydebs when at least trunk revision 1585 is built? (Or
build directly from the trunk source if you're comfortable with that.)
It should try to determine whether the printer supports the color model CMYK or
if not then at least
RGB and request that to be used.
** Changed in: qpdfview
Assignee: (unassigned) = Adam Reichold (adamreichold)
** Changed in: qpdfview
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331646
Hello Teo,
this is a tough one: We use Qt's default printing dialog and so we have
no influence ourselves on which printer properties you can change and
which you cannot. But we will copy those settings into our printing
request so they will be passed to the printer driver. And we can't
override
Hello again,
as pointed out in #1331646, the printing dialog itself is implemented by
Qt and not by qpdfview and hence we can't do anything about that (short
of replicating that functionality, but Qt is improving in this regard).
What would be a bug is if you could change that in other software
Hello Teo,
seems like you and Benjamin have already worked out most of this. Have
you also tried out the Prefetch option in the settings dialog? It
should make qpdfview prefetch to upcoming pages in both forward and
backward directions with the range being controlled by the Prefetch
distance
Qt Creator might be a bit heavy for just testing this, JuffEd seems
to be in the Ubuntu repository and also use the default Qt printing
dialog. (From trying this out here using Qt4, I can do edit those
settings using JuffEd as well as qpdfview. (You have to double click the
values to change to
Hello again,
I search the Qt code base and apparently the ColorMode is respected
when printing to PDF or under Windows but ignored for printing with
CUPS. (Maybe because of the problem that it is unclear whether to set it
to CMYK or RGB. I'll have to do more research on that.)
Regards, Adam.
--
Hello again,
the root cause of both problems seems to be how Qt's printing dialog
handles the printer properties and what qpdfview makes of it,
specifically the color mode which Qt seems to ignore anyway (and
qpdfview only uses to force grayscale but not color), would it be OK for
you if we merge
Ok, since bug report #1331662 seems resolved, we are still left with the
question on how to force color mode, i.e. deciding whether to request
CMYK or RGB as the input color model for the driver.
** Changed in: qpdfview
Status: New = Triaged
** Changed in: qpdfview
Importance:
Just to understand this correctly, in other applications, is it possible
color output while having the Print Quality at Draft Grayscale? I.e.
does Print Quality override the color mode setting? (Because the only
thing that I can generically request from CUPS is the color mode of the
content it
Hello again,
to report cache misses, we would have to start tracking which pages we
ever rendered independently of the cache and we would need some
heuristic to decide when a miss is normal (we just dropped it because we
had other stuff to render and cache) or notable because it happens too
Hello again,
I installed the Boomaga virtual printer under openSUSE and tested it
using lp with the same results. Hence I'll mark this as invalid as it
is not a bug within qpdfview. I am not even sure if it is a bug at all,
since it might be the intended behaviour of Boomaga as it allows you to
Hell again,
qpdfview definitely does not check the kind of print device and does
nothing more than request CUPS to print a specific pange range, i.e. it
doesn't even restrict the pages forwarded to CUPS itself. Did you try
another PDF viewer or even better using the command-line tool lp
directly
Hello,
ok, that's probaly due to qpdfview leaving most of the work of printing
to CUPS. :-\ Evince preprocesses much more heavily.
If the virtual printer is your default one, using lp should reduce to
calling lp -P page-range file-name on the command line.
Best regards, Adam.
--
You received
Hello,
Thanks for taking the time to report this issue. It seems hard to
diagnose what the problem is, hence I need more information: Does
printing the whole document work with your current settings? Do you have
anything set in the Page ranges field of the extended print options?
(This fields
(I am also willing to help to find out if the problem maybe in
qpdfview's use of libspectre still, but for that an example file would
be necessary.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hello,
possibly not overly helpful, but I what to add that libspectre is just a
thin and sometimes fragile wrapper around Ghostscript. So even if
libspectre did not change, maybe Ghostscript did and libspectre did not
adjust accordingly? Also libspectre does tend to print some sometimes
useful
Sorry, as Benjamin pointed out to me, there is an EPS file attached
which I overlooked. Sorry for that. Running a current Arch Linux and
qpdfview's trunk, the file opens and renders, but it does not rotate
correctly. According to [1] this can't be helped with pure PostScript
documents sometimes,
An Ubuntu and qpdfview user seems to have had the same problem trying to
print
https://service.rundfunkbeitrag.de/e360/e364/e1685/e1699/resources1700/Buergerinnen_und_Buerger_Wohnungsabmeldung_0106.pdf;.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Concerning printing with Evince: I think it converts the PDF to
PostScript before sending it to CUPS for printing hence flattening the
interactive features. The problem manifests only if one tries to use
lp (or similar commmands) directly or if the application (like
qpdfview) tries to take
** Also affects: qpdfview (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qpdfview (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1024227
I do see this behavior on a regular basis but I also run Opera, so I
start to believe that Opera at least triggers something other programs
don't.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/859723
Exactly the same problem here, after using the alternate CD to install
Ubuntu 11.04 with the command line only and installing the package
lubuntu-desktop afterwards on a memory constrained system, gksu uses the
su instead of sudo authentication method by default.
But I was able to solve the
31 matches
Mail list logo
