Age | Commit message (Collapse) | Author |
|
Storing raw pointers in structs is a questionable idea, given
that we've got string classes to auto-manage lifetimes of the
underlying storage.
Also, return FX_TXTRUN while we're at it, since we count on RVO
removing copies nowadays.
BUG=pdfium:480
Review URL: https://codereview.chromium.org/1900743004
|
|
Use the more standard name "clear()" instead.
Review URL: https://codereview.chromium.org/1888103002
|
|
BUG=
Review URL: https://codereview.chromium.org/1882043004
|
|
BUG=
Review URL: https://codereview.chromium.org/1885973002
|
|
Clean up three 4701 warnings (use potientially uninitialized variable)
which are the only ones left;
Re-enable warning 4701 for GN build;
Remove an unused data structure;
BUG=pdfium:29
Review URL: https://codereview.chromium.org/1885093002
|
|
This CL removes IFX_ArabicChar, IFX_RTFBreak, IFX_TxtBreak, IFX_WordBreak,
IFX_FormatString, and IFX_GSUBTable. References were updated to be the concrete
classes.
The CFX_GSUBTable was also removed as it is unused.
BUG=pdfium:468
Review URL: https://codereview.chromium.org/1882213002
|
|
Attempting to open bug_434.pdf on my Linux box would fail with:
../../xfa/fxfa/app/xfa_fwltheme.cpp:96: virtual FWL_ERR
CXFA_FWLTheme::Initialize(): Assertion `__null != m_pCalendarFont' failed.
I tracked the regression back to [1].
The issue seems to be in CFX_FontManager::AddInstalledFont we will only add
one font for a given Charset. In my case I end up loading 6 charsets, but the
fonts are all strange ones. When I open the PDF, it fails to find 'Arial'
because I've registered these other fonts.
To fix this I changed the m_FaceArray into a struct of {name, chraset}. Then
we record all fonts into this list and search over that list for the charset
when needed. This allows bug_434.pdf to open and the test to pass successfully.
1- https://pdfium.googlesource.com/pdfium/+/fe73e7849b8b4ce49408d2f52f3fc29b370b82b5
Review URL: https://codereview.chromium.org/1874433002
|
|
Neither are implemented. Removed.
BUG=pdfium:468
Review URL: https://codereview.chromium.org/1872463002
|
|
The naming is redundant given the base type, and will stand
in the way of consolidating Byte and Wide code.
BUG=
Review URL: https://codereview.chromium.org/1862123003
|
|
It doesn't persist the string beyond the duration of the
call, hence it should take the *StringC variant. Doing so
avoids some allocs by changing to the *StringC ctor in a few
places, at the cost of some explicit .ToByteStringC() calls
(which are cheap).
Review URL: https://codereview.chromium.org/1862953004
|
|
This CL is a straight move of the fxge includes into core/fxge/include.
Review URL: https://codereview.chromium.org/1868533002
|
|
No functional change intended.
This difference in naming is standing in the way of consolidating
some of the string code between Wide and Byte strings. The Wide
code wants to call raw_str() in exactly the same spots that the
Byte code calls c_str(). This makes sense, because in both places we
get a character type back, and not a uint*_t type. If WideStringC
had a raw_str() method, it would have to return uint32_t or similar.
R=dsinclair@chromium.org
Review URL: https://codereview.chromium.org/1863593004
|
|
Companion to https://codereview.chromium.org/1853233002
BUG=
Review URL: https://codereview.chromium.org/1857073002
|
|
This CL updates CFX_ByteStringC to use the more common c_str
and raw_str instead of GetCStr and GetPtr.
Review URL: https://codereview.chromium.org/1857713003
|
|
Having this happen implicitly can be dangerous because the lifetime
has to be considered; we should have caught the "red bots" in
https://codereview.chromium.org/1847333004/#ps60001 at compile time.
Review URL: https://codereview.chromium.org/1853233002
|
|
In XFA, we were constructing some CFX_ string types before
we reached main(). Setting breakpoints on these as well as
main() shows we hit main first after applying the patch.
Doing so also turned up an unused variable, presumably because
the static initializer made it appear used.
Review URL: https://codereview.chromium.org/1846353002
|
|
This CL splits the handling of CData sections out to an individual phase
of the parser. This fixes the issue with the CData parser getting confused
by < characters inside the data section.
BUG=pdfium:90
Review URL: https://codereview.chromium.org/1842633004
|
|
Some headers were missed in the previous CL.
Review URL: https://codereview.chromium.org/1835703002
|
|
Review URL: https://codereview.chromium.org/1830323006
|
|
This CL moves the fxcrt code into the core/fxcrt directory. The only exception
was fx_bidi.h which was moved into core/fxcrt as it is not used outside of
core/.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1825953002 .
|
|
It isn't buying us anthing, and it looks strange in
a struct when other uint types are already present.
R=dsinclair@chromium.org
Review URL: https://codereview.chromium.org/1821043003 .
|
|
Remove some tables from .h file (risk of duplication).
R=ochang@chromium.org
Review URL: https://codereview.chromium.org/1814233005 .
|
|
This CL adds the needed DEPS files to make checkdeps pass correctly. The
checkdeps PRESUBMIT method has been copied from Chromium and is enabled on
CL upload.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1801923002 .
|
|
This CL moves the xfa/src files up to the xfa/ directory and fixes the includes,
include guards, and build files.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1803723002 .
|