summaryrefslogtreecommitdiff
path: root/fpdfsdk/src/fpdf_sysfontinfo.cpp
AgeCommit message (Collapse)Author
2015-07-23FX_BOOL considered harmful, part 2.Tom Sepez
Fully automatic change, execpt for cleanup in fx_system.h R=thestig@chromium.org Review URL: https://codereview.chromium.org/1254703002 .
2015-07-23Fix FX_BOOL type mismatches.Tom Sepez
Extracted from https://codereview.chromium.org/1252613002/ R=thestig@chromium.org Review URL: https://codereview.chromium.org/1253603002 .
2015-06-11Remove trailing whitespaces in fpdfsdk.Lei Zhang
R=tsepez@chromium.org Review URL: https://codereview.chromium.org/1173343004.
2015-06-10Remove typdefs for pointer types in fx_system.h.Tom Sepez
This involves fixing some multiple variable per line declarations, as the textually-substituted "*" applies only to the first one. This involves moving some consts around following the substitution. This involves replacing some typedefs used as constructors with better code. R=thestig@chromium.org Review URL: https://codereview.chromium.org/1171733003
2015-06-08Remove more cruft from fx_system.hTom Sepez
- include system headers first and alphabetize. - remove unsupported FX_WIN32_MOBILE symbol. - actually define a FX_WIN64 symbol and make consistent. - use final/override, not FX_FINAL. - let stdint.h resolve FX_WORDSIZE concerns. - unused FX_ERR and FX_SUCCESS() macros. - unused FX_LSB_FIRST macro. - outline FX type deprecation plan. R=thestig@chromium.org Review URL: https://codereview.chromium.org/1169963003
2015-05-12NEW public API for pdfwindow font manipulation.chromium/2402chromium/2401chromium/2400Tom Sepez
PDFium side of fix to make chromium free of private header includes. This moves the one snippet of contaminating code from chrome to PDFium itself. BUG=486818 R=thestig@chromium.org Review URL: https://codereview.chromium.org/1126283004
2015-05-11Create top-level public/ header directory.Tom Sepez
These are the only files that embedders of PDFium should be including. They are entirely self-contained, and compile cleanly against -Wall so as to not offend the code that may include them. Having done this, we can see that chromium is pulling in two additional files from the fpdfsdk/include/pdfwindow directory, which is not guaranteed to work. A few files are renamed, adding an "_" to make the names consistent. The exception is fpdfview, which is doc'd as such in the doc. Naturally, paths will need updating in a handful of files in chrome when this rolls in. BUG=pdfium:154 R=thestig@chromium.org Review URL: https://codereview.chromium.org/1135913002
2015-04-17Replace FX_NEW with new, remove tests from fpdfsdkTom Sepez
R=thestig@chromium.org Review URL: https://codereview.chromium.org/1089823004
2015-01-09Fix -Wnon-virtual-dtor compiler warnings.Tom Sepez
This is done by explicitly adding a virtual dtor to interface classes, since the cost is small given that there are already virtual functions. The exceptions are for classes that have a Release() or Delete() method, in which case it is non-virtual and protected to indicate that the virtual class is never the deletion point. BUG= R=brucedawson@chromium.org, thestig@chromium.org Review URL: https://codereview.chromium.org/810883005
2014-08-13Add FX_OVERRIDE and use it for virtual functions of FX_FINAL classes.Tom Sepez
Should there be cases where this fails to compile, it indicates a mistake, either an incorrectly declared overrriden virtual method, or a method that should be declared non-virtual. The only issues were with CPDF_CustomAccess::GetBlock(), CPDF_CustomAccess::GetByte(), and CPDF_CustomAccess::GetFullPath(). These don't appear to be used anywhere, and are removed. Two members are removed that are no longer needed once those methods are removed. R=jam@chromium.org, jun_fang@foxitsoftware.com Review URL: https://codereview.chromium.org/454983003
2014-07-18pdfium: Fix all -Wdelete-non-virtual-dtor violations on Mac.Nico Weber
Calling `delete` on an object of a type that has virtual functions but not a virtual destructor is questionable: Since the object has virtual functions, it likely has subclasses, so if it's deleted through the base pointer and the destructor isn't virtual, the subclass destructor won't be called. In most cases, the classes getting deleted can just be marked final to tell the compiler that it can't possibly have subclasses (this also enables the compiler to generate better code). Two classes didn't have any sub- or superclasses but virtual functions - this doesn't make sense, so make all methods of these classes non-virtual. (Also delete an unused function on one of the two classes.) In one case, a class actually did have a subclass that needs to be deleted virtually, so mark one destructor as virtual. BUG=none R=bo_xu@foxitsoftware.com Review URL: https://codereview.chromium.org/370853002
2014-05-17Initial commit.John Abd-El-Malek