Age | Commit message (Collapse) | Author |
|
This CL renames DLLEXPORT to FPDF_EXPORT and STDCALL to FPDF_CALLCONV to
be more PDFium specific.
This is split off of https://pdfium-review.googlesource.com/c/8970 by
Felix Kauselmann.
Bug: pdfium:825
Change-Id: I0aea9d43f1714b1e10e935c4a7eea685a5ad8998
Reviewed-on: https://pdfium-review.googlesource.com/10610
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
builds."
This reverts commit 00334675c18a0203f313cceb670c970a77280f49.
Reason for revert: Breaking the deps roller - https://chromium-review.googlesource.com/c/609307
Original change's description:
> Add a build target and a proper export header for shared library builds.
>
> This CL adds support for Chromium's component build feature to pdfium.
>
> The export header stub in fpdfview.h is expanded to match Chromium's
> export mechanisms and patterns (fixes pdfium:825).
>
> A component/shared library build can be triggered by adding
>
> is_component_build = true
>
> as a gn argument. Please note that setting this will also affect some
> of pdfiums dependencies like v8, which will be build as components
> too.
>
> Additionally, this CL provides a "pdf_source_set" template which
> dynamically enables the use of "source_set" when building a complete
> static library or a shared library to reduce build time.
>
> When testing this it is recommended to only build the pdfium target as
> most of pdfiums test rely on non-public functions which aren't exported
> by the shared library.
>
> Bug: pdfium:825,pdfium:826
> Change-Id: Icedc538ec535e11d1e53c4d5fabc8c064b275752
> Reviewed-on: https://pdfium-review.googlesource.com/8970
> Reviewed-by: dsinclair <dsinclair@chromium.org>
> Commit-Queue: dsinclair <dsinclair@chromium.org>
TBR=thestig@chromium.org,tsepez@chromium.org,brucedawson@chromium.org,dsinclair@google.com,dsinclair@chromium.org,licorn@gmail.com
Change-Id: Ib02af2298932481293f50d362ae87bfedf284821
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: pdfium:825, pdfium:826
Reviewed-on: https://pdfium-review.googlesource.com/10550
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
|
|
This CL adds support for Chromium's component build feature to pdfium.
The export header stub in fpdfview.h is expanded to match Chromium's
export mechanisms and patterns (fixes pdfium:825).
A component/shared library build can be triggered by adding
is_component_build = true
as a gn argument. Please note that setting this will also affect some
of pdfiums dependencies like v8, which will be build as components
too.
Additionally, this CL provides a "pdf_source_set" template which
dynamically enables the use of "source_set" when building a complete
static library or a shared library to reduce build time.
When testing this it is recommended to only build the pdfium target as
most of pdfiums test rely on non-public functions which aren't exported
by the shared library.
Bug: pdfium:825,pdfium:826
Change-Id: Icedc538ec535e11d1e53c4d5fabc8c064b275752
Reviewed-on: https://pdfium-review.googlesource.com/8970
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
Currently Find() and other methods that return a FX_STRSIZE return -1
to indicate error/failure. This means that there is a lot of magic
numbers and magic checks floating around. The standard library for
similar operations uses a npos constant. This CL implements
FX_STRNPOS, and replaces usages of magic number checking. It also does
some type cleanup along the way where it was obvious that FX_STRSIZE
should be being used.
Removing the magic numbers should make eventually changing FX_STRSIZE
to be unsigned easier in the future.
BUG=pdfium:828
Change-Id: I67e481e44cf2f75a1698afa8fbee4f375a74c490
Reviewed-on: https://pdfium-review.googlesource.com/9651
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
U+D800 to U+DFFF should not be encoded in UTF-16. However, FreeType may
have charcodes in that range, so in that case we just say that the
corresponding unicode is U+0000, NULL.
Bug: chromium:732272
Change-Id: I64e82856bab7f69545a307da1fef4df7f9df1f00
Reviewed-on: https://pdfium-review.googlesource.com/7312
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
Bug: pdfium:731
Change-Id: I8005ca2c2d4a65ad2197ba6f71ee37f1c1e5b5d8
Reviewed-on: https://pdfium-review.googlesource.com/6833
Reviewed-by: Nicolás Peña <npm@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
|
|
FXFT_Get_First(Next)_Char can return large unsigned values. This CL avoids
integer overflow and adds some missing checks regarding the ranges of the
values returned by those methods.
Bug: chromium:727086
Change-Id: Ice7bbb3759e384b7174680a82a2a9380c3611382
Reviewed-on: https://pdfium-review.googlesource.com/6436
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
BUG=pdfium:719
R=npm@chromium.org
Change-Id: Ifd9330de265f8419d588b65fbd6a6187f17badd1
Reviewed-on: https://pdfium-review.googlesource.com/5950
Reviewed-by: Nicolás Peña <npm@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
Freetype can get to values larger than 0x10FFFF, but our current implementation
of the ToUnicode mapping and the function FXSYS_ToUTF16BE does not support
these values.
Bug: chromium:724962
Change-Id: I7069f33429527dbf2d0bfd2033512fe909970c02
Reviewed-on: https://pdfium-review.googlesource.com/5810
Commit-Queue: Nicolás Peña <npm@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
Bug: pdfium:667
Change-Id: I8c3d07d2c533e6dd2a98099673b136c587c37a98
Reviewed-on: https://pdfium-review.googlesource.com/5630
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
In particular, prefer an explicit .release() call when handing
ownership of an object to a caller across a C-API.
Change-Id: Ic3784e9d0b2d378a08d388989eaea7c9166bacd1
Reviewed-on: https://pdfium-review.googlesource.com/5470
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
Bug: pdfium:667
Change-Id: I811571c334ff28162905a65781ca14f03caf2966
Reviewed-on: https://pdfium-review.googlesource.com/4910
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
Add a comment to clarify and remove some unneeded checks.
Change-Id: I8b0492548b245abc45e161085047c9f36d6c8e2b
Reviewed-on: https://pdfium-review.googlesource.com/4871
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
Change-Id: I5d452ea907f4d243645ddae3512776096a827522
Reviewed-on: https://pdfium-review.googlesource.com/4872
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Nicolás Peña <npm@chromium.org>
|
|
This CL adds ToUnicode for CID fonts and adds a test to prove that using it
works as intended. The test uses a Linux font for Japanese characters, and
tests for other OS will be added in a followup.
The ToUnicode works by defining the PDF charcodes as equal to the glyph indices
and assuming that the freetype charcodes given by FXFT_Get_Next_Char are in
fact the unicode values.
Bug: pdfium:667
Change-Id: I419724b87c3936c730a05f771548ae4787a576eb
Reviewed-on: https://pdfium-review.googlesource.com/4810
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
There is already a method to add text from standard font, this CL adds
an option to add text using a loaded font. The font set into a text object
is ref counted and may be released, so call LoadFont on this new text obj,
and add a method to close the font. This CL also improves the SetText method
so that it now uses a WideString, in preparation for CID fonts with non-Latin
characters.
Bug: pdfium:667
Change-Id: I6829d702357d2a898a12f5297e4fd2ec993a9891
Reviewed-on: https://pdfium-review.googlesource.com/4770
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
Change-Id: I9dc32342e24361389841ecba83081a97fc043377
Reviewed-on: https://pdfium-review.googlesource.com/2959
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
|
|
The new method replaces the previous one for loading only type1 fonts. This
will create the font dictionary with the very basics needed, according to the
tables in chapter 5 of the PDF spec. The tests for now are only checking that
the information is getting passed on properly. Followup: adding text with those
fonts, generating the contents (doing that will allow testing whether the parts
that I've skipped like Encoding and cmaps are needed or not).
BUG=pdfium:667
Change-Id: Id1a61501e09542804a391552fd002f2caed41939
Reviewed-on: https://pdfium-review.googlesource.com/2915
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
Given a stream of data, we create a type1 font and fill up the required
dictionary entries according to PDF spec 1.7. Table 5.8 describes Type 1 font
dictionaries, and Table 5.19 describes font descriptors.
BUG=pdfium:667
Change-Id: I571b09fb533467d77ed0104e613726387aec1f87
Reviewed-on: https://pdfium-review.googlesource.com/2835
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
BUG=pdfium:667
Change-Id: I05e301385a7af4b6ce27dc0b885e23646abf3dd9
Reviewed-on: https://pdfium-review.googlesource.com/2711
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|