| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
The pdf14 color mapping procs clearly had some issues as they are reading uninitialized
memory and using transfer functions that would not make sense with changing
color spaces. Also, the soft mask should not be going through the effective_transfer.
It has its own transfer function to deal with. Careful reading of the PDF spec revealed
that the transfer function is only to be used if the color being drawn is opaque. It
states that this is true if the blend mode is normal, stroke and fill alpha are 1.0, and
no soft mask is present. Also, an image that has a soft mask does not use the transfer
function. These changes resulted in a lot of diffs. I reviewed them and
did some checking of color values to verify things are ok.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #702946 "Ghostscript creates PDF originals with black stripes"
This is another case of the problem in bug #702900, The commit to fix
that problem (d5494de2cab28b91ba360d15b8afffef50a3f421) fixed four
places in the code, but missed a fifth place because it is distant from
the other four. The offending procedure is setstrokeforTrpreservation.
This commit adds the required code to that location to go along with the
other four, at the same time:
1) Move the actual code to calculate the width into a procedure
2) Have all 5 places use that procedure
3) Improve the non-square calculation (hypotenuse/2 instead of hypotenuse)
4) Add some 'tolerance' to the equality test.
The tolerance is because both the test file here and in 702900 have a
CTM which is minutely non-square. In this case the c and y scaling
differ by less than 0.0001. The intention of this code is actually to
deal with non-square resolutions, rather than non-square CTM, and it
does so by calculating the hypotenuse of a triangle where the x an y
values are the linewidth in each direction. In fact the hypotenuse/2
seems a closer approximation. But in any event its incorrect, better to
simply use the linewidth if the difference between the two is not very
large. (eventually, with pdfi, we will probably do away with this
horrible kludge entirely)
This causes minor but useful progressions in the test suite files
Bug695841.pdf, clipping_image_problem.pdf and
sumatra/712_-_image_not_displaying.pdf. most notably the latter.
It also produces slightly less bold output for the test file here,
which Acrobat shows as matching precisely with the original.
|
|
|
|
|
|
|
|
| |
This reverts commit 66c2469c7d4543f32d6dc93edf1d649e809b8419.
A user got in touch to say that he maintains a printer driver "back end" that
uses the opvp device. So reinstating it - at least we know it's getting
tested.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, we look in TESSDATA_PREFIX (if defined).
If not found there, we look in ROMFS (in tessdata).
If not found there, we look at the configured "tessdata" path
(which defaults to ${datadir}/tessdata). (${datadir} defaults to
${prefix}/share on unix, and ${gsrootdir} on windows.)
If not found there, we look in the current directory.
Update doc/Devices.html (and fix some indexing).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #702961 "GS produces significantly larger PDFs with same settings as Adobe Distiller"
This is a problem with the interaction of various image parameters. The
relevant options are PassThroughJPEGImages, ColorConversionStrategy and
AutoFilterColorImages.
Because PassThroughJPEGImages is true, we don't set up a compression
filter (we don't want to apply compression to a DCT compressed data
stream). But ColorConversionStrategy is /sRGB, so we then turn off the
PassThroughJPEGImages (we cannot change the colour model and still
pass through the original data, obviously). Ordinarily the compression
chooser would then select a compression based on the result, but
AutoFilterColorImages is false, so the compression chooser is disabled.
The result is that we write uncompressed image data to the file.
By reordering the code so that we check the ColorConversionStrategy
earlier we can turn off PassThroughJPEGImages before selecting the
initial compression which means that this p[articular sequence of
options will then work as expected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Map all text to black. This is achieved by altering the
color space to DeviceGray with a fill of black during
gs_text_begin. When gs_text_release occurs, the color space
is restored. This will only occur with the option -dBlackText
and if the text is actually to be drawn.
When going to a raster device, the stroke and stroke fill of
the text is handled with a stroke or stroke fill command.
My original plan of storing the old color spaces and client
color in the text enumerator will not work in this
situation as it the enumerator will have already been
destroyed when the stroke or stroke/fill command occurs.
For this reason I store the old color space information
for the current and alternate color spaces
in the graphic state. The structure holding the information
is garbage collected as it is holding objects that may be
garbage collected. We also need to know if the target
was a high level device like pdfwrite, as that device
will handle the fill AND stroke, and we will need to restore
the color space when we tear down the text enumerator.
gs_text_release needed to have the pgs added as a parameter
to allow the possible release of the blacktext structure
when the text is released from the other languages. This
did not seem to be too big of an issue as gs_text_begin
passes the pgs also. If the pgs is not available, NULL can
be passed, and that is done in several locations.
A new special op was added to let us avoid doing the black
text setting if we are constructing a soft mask. If we did not
do this the mask could result in the loss of the text.
Finally, Type 3 fonts will NOT be affected by this process.
Type 3 fonts are often used for actual graphic logos etc.
Ken Sharp suggested we not have them affected by this setting.
There were also issues with trying to do type 3 fonts in
in that the PDF interpreter does some color space settings
of its state when dealing with type 3 fonts and this put the
interpreter's state out of sync with the graphic library state.
This was tested with a forced setting of black text enabled.
No seg faults or errors occurred. There were obviously a lot
of differences reported (over 33,000). All the images that were available
to me with bmpcmp were gone through. Problems were found
and addressed (the soft mask issue for example was found,
as were issues with color spaces not getting properly restored).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #702964 "EPS file hangs with pdfwrite"
This is not related to the hang, but to the remaining problem with this
file and pdfwrite.
When using pdfwrite with PassThroughJPEGImages the output is incorrect.
The reason is that the PostScript program processes the JPEG compressed
data, turning a 4-component CMYK image into a single component gray
image.
Obviously if we pass through the original CMYK data, but declare the
image a DeviceGray the result is incorrect.
The only way to deal with this is to turn off the feature. There's no
simple way to do this in pdfwrite (where we normally decide to turn it
off, for downsampling etc) without disabling it for a number of other
useful cases. So instead add a new IdiomSet which replaces part of the
PPI ColorUtils ProcSet with a redefined procedure which turns off the
PassThroughJEPGImages feature if the ProcSet forces Gray output.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #702964 "EPS file hangs with pdfwrite"
This is only a partial fix for the bug report, the remaining problem
is addressed in a following commit.
The problem here is that the EPS file includes a ProcSet which processes
the JPEG compressed data. It does so using a procedural DataSource for
the image operator. Unfortunately the procedure fails to spot that
readstring returns 0 bytes and identify this as en EOD. Instead it
continues to try and read data, which continuously fails.
While the cause of the hang is in the PostScript program, it does not
normally exhibit because the image operator ceases to read data from the
DataSource when it has read enough samples to satisfy the declared
Width/Height/BPC. An oversight in the pass-through code meant that the
image operator wasn't properly terminating even when enough data had
been supplied.
This commit correctly returns either 0 (require more data) or not-zero
(enough data read) so that the operator terminates.
|
| |
|
|
|
|
| |
before we use it.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no immediate prospect of resolving the underlying issue: that the
stream code requires the data pointer in the "cursor" to be initialised to the
address one byte *before* the beginning of the actual buffer.
We also do not want to disable the array bounds warning completely, as that
risks missing real mistakes.
So, define a static inline function which does the offending pointer assignment,
and disable the warning locally, for only that function. Then have everywhere
that uses such a buffer setup call that function, rather than do the assignment
itself.
At the moment, it is only disabled for gcc (and compatible) compilers, we can
add others if/as required.
|
|
|
|
|
|
| |
ASCII85Decode filter: We correctly bounds check the buffer size, but dumbly
were doing so *after* we'd used the relevant indices into the buffer. Change
that order, and add another check.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the compiler parameters around so the third party lib specific -I options
come first - hopefully meaning we'll favor any included headers over those in
the system include path(s).
This assumes the compiler searched include directives given on the command line
left to right. Apparently this used to be a problem, I've not found a recent
compiler that breaks that assumption (yet!).
This applies to: expat, freetype, ijs, jbig2dec, jpeg, jpegxr, openjpeg, png
tiff and zlib
|
|
|
|
| |
to match the other platforms.
|
|
|
|
|
| |
We already get the libs, missing the CFLAGS (mainly the -I) was just an
omission.
|
|
|
|
| |
Docs/dates/version for 9.53.3
|
|
|
|
|
|
|
| |
This only affects the pdfwrite device.
It was rescaling the /L entry for no apparent reason, which meant the
Line annotations rendered incorrectly when they had no AP.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'd thought that we had missed off the %Invocation from the PDF output
of the PDF image devices, but in fact it was only that the pdfocr
devices had it emitted in a surprising place in the file.
That's fixed here just by moving when we write it so that its location
is consistent between the devices.
Moved some definitions common to both pdfimage and pdfocr from the
device's .c files to the pdfimage.h file.
Added emission of a very basic /Info dictionary. To facilitate future
enhancements the number of 'static' (ie predefined) objects has been
turned into a #define and we use that wherever possible instead of the
previous hard-coded magic number. Because of the font objects required
for pdfocr, and the fact that they refer to each other, these still
don't use the #define and will have to be manually adjusted if we ever
change this again.
Acrobat ignores the /Info dictionary, apparently it only reads the XML
/Metadata values (at least in modern versions), so adding the Info
dictionary doesn't help. Creating the XMP metadata is unfortunately
quite complicated, we'd need to steal quite a bit of code from pdfwrite
and at the moment I think its more trouble than its worth. I may change
my mind in future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the allocations from the bitmap cache are aligned to the platform's
required alignment, see commit:
260c443bc14cdffa4d94e14c3a57e35bebee3a5b
We also want the initial size of the memory pool used by the cache to be
"aligned".
This is so that code that attempts to identify cache entries to evict by
requesting a size equal to the entire size of cache memory pool doesn't get an
unexpected failure, because we've rounded up that allocation request to a value
larger than the entire size of the memory pool.
Because we don't expect an error to be possible at that point, a crash can
occur.
Of the "normal" platforms we use, this only exhibits on Win32 because that is
the only platform where the align_bitmap_mod we use is less than the
obj_align_mod used for the memory managers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found during Windows testing for a release.
The full test file for
https://bugs.ghostscript.com/show_bug.cgi?id=693365
would cause Ghostscript to crash due to an ICC profile being freed whilst a
reference was still being held for it. That was not counting up a reference
count when restoring the device profile back to a previous value.
Fixing that introduced a leak for other profiles. And that turned out to be
not decrementing the reference count when replacing a device profile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VS2019 release builds crash with the input file from bug 702916 and several
other files, in copied_glyph_slot() because the pointer retrieved and stored
in *pslot is non-sensical.
Debug/Profile builds and optimised builds with earler VS versions don't show
the problem.
Adding debug code to assign the calculated index to an interim unsigned integer
variable also cause the problem to go away.
So, use that as a workaround.
|
|
|
|
|
|
| |
And a whitespace/indentation issue.
Noticed in passing....
|
| |
|
|
|
|
|
| |
s/RepiredAnError/RepairedAnError/ A simple typo that was missed because
we did not have a test file with a format error to trigger this code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For efficiency, the glyph cache allocates "large" blocks of memory into which
it parcels out offsets for individual glyph cache bitmaps, as required.
Since cached glyphs are usually fairly small, and potentially can be short
lived, this saves the overheads of "full" memory for every cached glyph.
Unfortunately, in calculating the offsets for the cached glyph, it was failing
to account for the required alignment of the system. In any environment that
strictly enforces aligned memory accesses, this will potentially cause a bus
error.
In this case, it was switching the gs_glyph type to a 64 bit type that triggered
the issue. But any changed to the contents of the cached_char struct could have
resulted in it happening.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 385a750c39e3112f4b640f8dbfea28fbad9885a2
Author: evrhel <ethanvrhel@gmail.com>
Date: Sun Sep 13 14:42:08 2020 -0700
Added several devices, updated documentation, and README.txt.
commit 64fad0d5035ccf7394c1863e369b108ca471b5fb
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Wed Sep 9 15:30:58 2020 -0700
Worked on PDFPostscriptDeviceFamily implementation
Added all of the parameter types specified in
https://ghostscript.com/doc/current/VectorDevices.htm for
PDF/Postscript devices.
Added several devices, updated documentation, and README.txt.
commit fc6593654f7d1e114d8fd0a8b2da89224e193c92
Author: evrhel <ethanvrhel@gmail.com>
Date: Wed Sep 9 14:19:25 2020 -0700
Added missing Settings class to viewer
commit ea92fe4f172911dfe79e8423bd7b98d14d585393
Author: evrhel <ethanvrhel@gmail.com>
Date: Wed Sep 9 14:19:25 2020 -0700
Added missing Settings class to viewer
commit 792ddf8525e903e55bf668b41b84f002ef4757cb
Author: evrhel <ethanvrhel@gmail.com>
Date: Sat Sep 5 14:04:44 2020 -0700
Added more implementations of Device class
commit 4f2056eafb633f5e4aa9f6ac3bed99247110f556
Author: evrhel <ethanvrhel@gmail.com>
Date: Sun Aug 30 16:11:20 2020 -0700
Added device classes to allow easy device manipulation
New abstract classes Device and FileDevice and several subclasses
to allow easy modification and output to devices.
commit ea360f254e7638b37529b8db105f0a2b9b7e722f
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Mon Aug 24 21:16:56 2020 -0700
Updated to newer Ghostscript version and fixed a bug
Updated to the newest Ghostscript version and fixed an
ArrayIndexOutOfBoundsException bug when unloading zoomed pages.
commit 34c47909939b4e85f18e2fc03088203c51bba292
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Sun Aug 23 15:58:44 2020 -0700
Added better documentation
commit eda31b70496337caefd0dc912c5a0850de769147
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Thu Aug 20 14:36:48 2020 -0700
Updated how zooming is handled
Zooming is now done through the SmartLoader and is no longer
a separate operation. Fixed an issue when the SmartLoader could
become out of date due to the condition variable being signaled
before the SmartLoader had finished.
commit 5b08d9eadfe64d87cf26869c47a2a5f78755dd4b
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Wed Aug 19 17:38:34 2020 -0700
Implemented distilling documents
Users now have the option to distill a document if the desired
input is not a PDF.
commit 4a78a968777521f23fefaeb277d378b9dc08b555
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Tue Aug 18 15:04:09 2020 -0700
Fixed zooming and some other bugs in the viewer
Zooming in on documents in the viewer no longer causes a crash.
Fixed a bug where documents would not display after being loaded.
Fixed a bug where closing a document when none was loaded would
crash.
Fixed a bug where gsapi_delete_instance would cause a crash.
commit 9c9190192c1acdafbf4e9f277dba9e2079046cc7
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Sun Aug 16 16:28:44 2020 -0700
Fixed JNI bugs and began updating viewer to use one GS instance
Fixed JNI crashes when Ghostscript calls were made from different
threads. Migrated loading low res and high res images from using
multiple instances to using one global instance.
commit fbe9a961e7fef31c79cfd8ed857643ad00798af8
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Sat Aug 15 14:36:34 2020 -0700
Added init_with_args to the test code in Main.java
commit 96ede7306ce8d71be3016e7d708c801c5718fdfe
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Sat Aug 15 14:33:40 2020 -0700
Fixed a small error in test code in Main.java
commit dcb1141da6901f0c42336861428cf13f6cc9b202
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Sat Aug 15 14:13:23 2020 -0700
Finished updating to newer Ghostscript functions
Replaced all Reference objects in Ghostcript calls in Java
and JNI to Reference<T>. Iteration over parameters now must be
done through GSInstance instead of creating an explicit iterator.
commit aa9288fa60aa6030b88f909ac494b388737e1748
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Thu Aug 13 16:00:51 2020 -0700
Finished implementing the rest of Ghostscript functions in Java
All GS functions are now able to be called through GSAPI. Fixed
a possible memory leak related to exception checking in C++.
commit b02df334fdbc14fb1ed4d75bcaddcf7091391ee7
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Thu Aug 13 12:49:33 2020 -0700
Got gsapi_enumerate_params working in Java
Got gsapi_enumerate_params working and added a utility class
to do the same work as gsapi_enumerate_params with a Java
iterator.
commit 502baba9568406ce923944f693728af30c81473e
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Wed Aug 12 16:25:54 2020 -0700
Got gsapi_set_param working
Renamed java function to gsapi_set_param_once to distinguish from
the actual Ghostscript call. This method does the call to
gsapi_set_param twice in native code and is used to make it easier
to use the function in Java.
commit 614c55f1989d04178c916db56cfc38753918097e
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Wed Aug 12 13:30:07 2020 -0700
Worked on implementing new Ghoscript methods in Java
Wrote out all native method signatures in Java and C++. Workekd
on gsapi_add_control_path and associated helper methods.
commit 08cd824e589cf9cdd4848b9b3606898ac7141c9f
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Tue Aug 11 16:32:08 2020 -0700
Worked on improving References in C++ code
commit de7f2303372bed8b19ca401392151cba7f2ab013
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Tue Aug 11 13:58:54 2020 -0700
Progress on updating Java bindings to newest version.
Added some of the new methods, but currently none work.
commit bcf2db77c8c106b1b3d80d647b0fe04201d9c645
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Mon Aug 10 14:08:42 2020 -0700
Fixed some errors related to loading pages too fast
An error would occasionally be thrown in the SmartLoader having to
do with the Document being modified while in the SmartLoader, causing
an error. Reconfigured how the SmartLoader handles documents and
is started and stopped.
commit cb2be4f3b0635efd4616f567389b19a7351d078b
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Mon Aug 3 15:41:20 2020 -0700
Added thread safety to the viewer.
The viewer now ensures that no more than one ghostscript call is
happening at the same time and has multiple options for controlling
the behavior if multiple operations are attempting to be called.
Also began work on a utility class to make Ghostscript calls easier
by having a class carry around a instance and a caller handle.
commit f81dfc177f71d0d12b38371fae54b45e158833ce
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Sat Aug 1 17:16:43 2020 -0700
Progress on improving concurrency
Added better exception handling. Began progress on handling
concurrent operations better.
commit e0f4af0e59580dabca01cb9b932185475d4032a8
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Sat Aug 1 14:48:37 2020 -0700
Viewer now will load a higher resolution image on zoom.
The high resolution image loads correctly, but the viewer does
not correctly load the right page when in a zoom other than 1x.
commit 843914f25b1a58841bac94e5df8cded8b47dd948
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Wed Jul 29 15:40:14 2020 -0700
Optimizations to page loader
Page loader now only loads around where the use is viewing and
does not load pages unless the user actually navigates to those
pages.
commit 458f93f005920b9ca58bed67178dba26cd6d8a18
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Wed Jul 29 14:13:44 2020 -0700
Progress on viewer
Optimizations and easier user interface as well as basic zooming
implemented.
commit ab65f0672d2be5f5c312b229af66d8d028661d08
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Mon Jul 27 15:12:45 2020 -0700
Various bug fixes in viewer
Added utility methods in ViewerWindow.java to help with changing
pages and zoom levels. Added framework for zooming pages.
commit e3e7dbac2b5b271a4d4225ebae34d36f603b8a07
Author: evrhel <ethanvrhel@gmail.com>
Date: Fri Jul 24 14:03:54 2020 -0700
Got viewer working
Viewer now works and can open files. Still does not "smartly"
target pages which the use is directly viewing or take
advantage of file-specific properties. It instead loads all
the pages' high-resolution images in order.
commit f1441ed36302f75d94cf4aa4a8047150bf5b7585
Author: evrhel <ethanvrhel@gmail.com>
Date: Thu Jul 23 18:57:52 2020 -0700
Basic viewer working
The viewer has basic capabilities, but still lacks loading
high resolution images, spacing components, and resizing correctly.
commit ea3eecbc30b1a4a4747dfd2818262c2f6eea112c
Author: evrhel <ethanvrhel@gmail.com>
Date: Thu Jul 23 16:13:13 2020 -0700
Worked on creating GUI
Added GUI (generated using NetBeans). Added support for callbacks
into the GUI specifically related to the wanted viewer operations.
commit cb15f051db01135cf1eef8df6a8cfb53cb5ff840
Author: evrhel <ethanvrhel@gmail.com>
Date: Wed Jul 22 16:24:13 2020 -0700
Progress on Document class for handling a documentLoader
Document class is a list of Pages which stores a low-resolution image
and a high-resolution image. The low-resolution image should always
be loaded while the high-resolution can be unloaded to save memory
usage.
commit 99fa4ae3667cd58d6f2a72f01d1b9410929f4847
Author: evrhel <ethanvrhel@gmail.com>
Date: Tue Jul 21 15:19:10 2020 -0700
Converted original Java project to be used as a JAR library
The original project should be compiled as a JAR library and
where needed, should be placed alongside the required native
libraries to run. The executable Java project has been moved
to the gsviewer project.
commit 80dd426da705c160b79a57a161c5d95c3a57aca6
Author: evrhel <ethanvrhel@gmail.com>
Date: Tue Jul 21 15:01:18 2020 -0700
Colors now being displayed correctly after getting image
Fixed drawing colors coming from ghostscript. Next: need to migrate
the current project into a jar file instead of a runnable application.
The viewer will use the Java library.
commit 06a50542391c3f0ad64f20a0ae6a1f63d9aa61e0
Author: evrhel <ethanvrhel@gmail.com>
Date: Mon Jul 20 17:10:36 2020 -0700
Fixes to display callback and C++ and added window to display images
Fixed Java methods not being found in C++ and added a window class
to start displaying images.
commit 4b0e69075619f7c4ef8df850d0e85d125e2b67da
Author: evrhel <ethanvrhel@gmail.com>
Date: Fri Jul 17 16:02:37 2020 -0700
Implemented NativePointer methods in C++ and updated onDisplayPage
onDisplayPage now uses a BytePointer object for the pimage parameter
to interface into native memory.
commit 0d24844082f6c566af417ad35b394e3fd591c38e
Author: evrhel <ethanvrhel@gmail.com>
Date: Fri Jul 17 15:03:06 2020 -0700
Added new Java class allowing native access to memory blocks
Added NativePointer and NativeArray as two base classes for low-level
memory-access alongside other classes to assist with this.
commit 9643091f698293181dcb484e04e96d19df12950a
Author: Ethan Vrhel <ethanvrhel@gmail.com>
Date: Thu Jul 16 17:01:53 2020 -0700
Security improvements in native code
Fixed multiple points where the program could crash
and instead returned NULL and/or threw a (safer) Java
exception.
commit fdade3eedc6469edd3da510bd648a39fdb9f9a93
Author: evrhel <ethanvrhel@gmail.com>
Date: Tue Jul 14 15:52:22 2020 -0700
Fixed how display_callback was being passed to Ghostscript
The display_callback device did not have the correct values regarding its size,
major version, and minor version. Furthermore, the display_device structure
was not being dynamically allocated and ended up being freed too early.
commit 5a3e822ca0e076708bed843a2578a18eebb37f3d
Author: evrhel <ethanvrhel@gmail.com>
Date: Sun Jul 12 15:17:16 2020 -0700
Fixed some bugs related to stdio
Fixed stdio bugs and added some more utility methods to make calling
ghostscript functions easier in Java.
commit 88fad771fcd4024a538f4bf6f6819d62d8180440
Author: evrhel <ethanvrhel@gmail.com>
Date: Sat Jul 11 14:29:58 2020 -0700
Completed JNI bindings to Ghostscript
Added implementations for StdIO and display callback, and added
some testing in main().
commit bb197f9ae65b39bf55ae6fd932203e514472ff8f
Author: evrhel <ethanvrhel@gmail.com>
Date: Fri Jul 10 14:06:07 2020 -0700
Finished writing JNI bindings.
Finished writing JNI bindings and added more utility methods to
help with setting Reference objects in Java.
commit 8a0074ea3624921cd8ff98684e5efa2fc0b4d5ce
Author: evrhel <ethanvrhel@gmail.com>
Date: Thu Jul 9 18:27:52 2020 -0700
Progress on linking Ghostscript functions to Java
Added support for more functions and finished implementing display
callback functions.
commit 32fee0e8ea1d82897ff4d2a3ce4b9ba92a680cd3
Author: evrhel <ethanvrhel@gmail.com>
Date: Wed Jul 8 19:39:27 2020 -0700
Worked on implementing display_callback in Java
Added utility methods in C++ code to help with calling functions,
setting fields, and creating objects. Started to implement the functions
defined in display_callback.
commit fe751db5f899c3e59c961d65ec013f307adef8f9
Author: evrhel <ethanvrhel@gmail.com>
Date: Tue Jul 7 17:31:18 2020 -0700
Implemented Ghostscript functions in Java in the C++ project
Created a new C++ project which allows for Java calls into Ghostscript.
Current working functions are gsapi_revision, gsapi_new_instance, and gsapi_delete_instance.
gsapi_set_stdio_with_handle and gsapi_set_stdio are untested.
commit 4c2bf73539f440bf8f6b45d85820cc84df2e6b28
Author: evrhel <ethanvrhel@gmail.com>
Date: Tue Jul 7 14:52:47 2020 -0700
Finished writing ghostscript api signatures in GSAPI.java
commit 4850223d252d6e245104c42fafc0190b91177be2
Author: evrhel <ethanvrhel@gmail.com>
Date: Mon Jul 6 18:16:15 2020 -0700
Progress on creating the JNI bindings to Ghostscript.
Started GSAPI class to store exported Ghostscript functions. Added error constants and declared
gsapi_revision, gsapi_new_instance, gsapi_delete_instance, gsapi_set_stdio_with_handle,
gsapi_set_stdio, gsapi_set_poll_with_handle, gsapi_set_poll, and gsapi_set_display_callback bindings.
Added multiple callback interfaces and a Java representation of struct display_callback_s.
commit 8da16a603b124c15ce4dc7c7fccc97f711d75fb2
Author: evrhel <ethanvrhel@gmail.com>
Date: Mon Jul 6 15:18:32 2020 -0700
Java demo: Initial commit with README
|
|
|
|
|
|
|
|
|
|
|
| |
I am trying to use a hex string <XXXXXXXX> in pdfi.
The code had a bug in it (probably because the ps code never generates
a hex string?) that was incrementing the token to be 1 longer than it
should have been. Logic was just mangled.
I also simplified it to to take out the goto, which was egregious in
this case. Just put in two lines of code where it belongs, instead of
a goto to those two lines of code... (really?)
|
|
|
|
| |
That page is now gone.
|
| |
|
|
|
|
|
|
|
|
|
| |
Our "sanitize" target just uses address sanitizer.
With this commit, we'll still default to address, but the caller can do:
--with-santizer=memory
to opt for the "memory" sanitizer instead.
|
|
|
|
| |
(unused variables)
|
|
|
|
|
| |
In a few cases we were using the wrong element in the union to read the
value back from the param list (and to range check the values).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Annotations are somewhat odd and don't quite fit the scheme of other
cos objects. Each annotation is created as a dictionary, which is
stored in the Annots array (also a cos object)) of the page.
But we write the annots out to the file immediately, and free the
dictionary contents at that time. We cannot, however, free the dict
cos object, because we need the object number to write the Annots
array in the page dictionary, which we only do when writing the page
dictionary.
So at the end of the page the annots array contains a number of empty
dictionaries. We free the array, which would free the dictionary
contents (except there are none) but it does *not* free the dictionaries
because they have an ID......
So when we free the Annots array, we first need to set the ID of each
of the dictionary objects it contains to 0, so that the dictionary
will also be freed.
|
|
|
|
|
|
| |
This implementation was missing, just copy-pasted the default for it.
It was going through a code path that I think only works for Widgets.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has the obvious benefit that the interpreter will skip processing
pages except those that lie in the FirstPage LastPage range.
If the PageList is used, the XPS interpreter will create a new
list of linked pages to process. The XPS interpreter handles all
the PageList cases currently implemented by the PDF interpreter
including even and odd. In addition, the XPS interpreter will handle
backward indexing (e.g. 100-1), as well as starting from last page
to another page (e.g. -2 which means from last page to second page),
and page repeats (e.g. 1,2,1,2,1,2 or 1-3,3-1 or 1-,-1 which is
do page 1 to end and end to page 1) Also, setting -dFirstPage=4
-dLastPage=1 will create pages 4,3,2,1
|
|
|
|
|
|
|
|
|
| |
A user reported (privately) that a pre-release of an upcoming XCode release
fails to compile due to a missing prototype/declation of abs() in the jpegxr
code. It's clearly a simple omission, as several files use abs() and do include
the relevant header.
So adding it here.
|
|
|
|
|
|
|
|
|
|
| |
The buffer size parameters for the fapi callbacks used to be unsigned short,
but were changed to ints a while back. The calls for the (g)subr data in
Type 2/CFF fonts hadn't had the casts to ushort removed, causing the values
to be trucated.
There was also a Postscript/FAPI internal function that had not had the
buffer length parameter changed to int.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, the Type 2 font serialisation (used for reassembling font
streams to pass to freetype) was using the FAPI callback to read the
(g)subr string data into it's main buffer, but then called the writing
function to write data to the buffer, using its own buffer as input -
effectively overwriting the bytes with the same bytes.
The only purpose (it seems) was to move the current stream position forward by
the appropriate amount.
Change it so we simply move the "current position" pointer on by the correct
offset.
|
|
|
|
|
|
|
| |
The memory allocated by param_write_string_array() was never being
released.
(Note: the cluster doesn't test this code path currently)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nancy discovered this one while working on annotations for pdfi. The
code here would attempt to free the memory pointing to the key name
which is passed as an argument to the function, if the *dictionary*
properties were set to free dictionary keys.
Obviously the function argument is not the same thing as the key stored
in the dictionary, so even at first inspection this looks incorrect.
The key is supplied (much higher up) from a param list, because the pdfi
code uses C param lists, where the data is stored in a single large
allocation, it is not possible to free an individual key and causes a
crash.
Ghostscript gets away with this for two reasons; firstly it uses a
stack param list (which is basically a ref param list) where each key
is stored in its own allocation. Secondly the key is not actually
allocated, its an entry in the interpreter name table. So when the
code in cos_dict_put_copy 'frees' the memory, nothing actually happens,
the memory manager just notes that the memory is unused now. This
avoids double freeing the memory which would otherwise happen.
So essentially this code is wrong, and we've been getting away with by
sheer luck for decades.
I tested the modification extensively, including memory leak checks with
many files run through pdfwrite and can find no problems with simply
removing the line of code.
|