Fix #56; and it is now the same as writexl::write_xlsx()
.
write_ods(list("some_car_data" = mtcars, "some_flower_data" = iris))
list_fods_sheets()
and read_fods()
cannot accept ~
as pathlist_fods_sheets()
can't guard non-fods XML disguised as fodsSee discussion #133
fix #135 and the review by Dr Ruedni
# Specifying col_types as shorthand, the third column as factor; other by guessing
read_ods("starwars.ods", col_types = "??f")
# Specifying col_types as list
read_ods("starwars.ods", col_types = list(species = "f"))
minty
instead of readr
to reduce the number of dependenciescpp11
to avoid the "non-API calls"trim_ws
for colnames
behaves the same as readxl::read_xlsx()
.read_ods()
and list_ods_sheets()
can also be used to process flat ods files. read_fods()
and list_fods_sheets()
are still available, but not as the so-called "common interface."read_ods()
and read_fods()
have two arguments - trim_ws
and n_max
which are the same as the arguments of readxl::read_excel()
.Significant speed improvement; also xml2
is no longer a dependency.
Prior the previous stable release, <= 1.9.0, reading single-row / single-column with col_names = TRUE
/ row_names = TRUE
produced errors.
In v1.9.0 (and the stable version v2.0.0 on CRAN), reading single-row / single-column (F)ODS with col_names = TRUE
/ row_names = TRUE
will
override the two parameters and return a non-empty data frame. This behaviour is consistent with other data reading R functions (see #146) such as readxl::read_xlsx()
, readr::read_csv()
, data.table::fread()
, and openxlsx::read.xlsx()
. For these functions, either a empty or zero-row data.frame is returned.
We changed this behaviour. The following will return a zero-row data.frame by default.
read_ods(write_ods(mtcars[0,])) ## col_names is TRUE by default
However, the previous behaviour is in the stable release and backward compatibility is needed. If you need that previous behaviour, please set the options("readODS.v200" = TRUE)
options("readODS.v200" = TRUE)
read_ods(write_ods(mtcars[0,])) ## col_names is TRUE by default
write_fods
is available, fix #103
write_ods
has been partially rewritten in C++ #140
To ensure UTF-8 everywhere, fix #107
Bump requirement to R>=3.6
dttm
column was incorrectly written with one more column. It's now fixed.
The default for na_as_string
was getOption("write_ods_na", default = FALSE)
in v1.8. The default now is FALSE
, but it writes NA as blank cell (instead of the buggy behaviour of writing NA in the original type, which is rendered as 0 by LibreOffice for numeric types. see #79). This behaviour is compatible with the default of writexl::write_xlsx
.
The behaviour of na_as_string = TRUE
is the same as in v1.8: writes NA as string.
The descendant of getNrOfSheetsInODS()
is not very useful. If you really need to have the similar function:
length(list_ods_sheets("starwars.ods"))
overwrite
: always TRUEverbose
: always FALSEas_tibble
and .name_repair
as arguments. If as_tibble
is true, outputs as a tibble using tibble::as_tibble()
passing on .name_repair
(default being "unique"
). By default as_tibble
is set to TRUE.check_names
argument. All name repairs are now dealt with using vctrs::vec_as_names()
. This will significantly change the default names given to outputs. (Names in the style of check_names = TRUE
can be obtained by setting .name_repair = minimal
, although this is not advised)There are many reverse dependencies using ods_sheets
.
NEWS.md
file to track changes to the package.These have been deprecated for several years.
include_external_data
as an argument (FALSE
by default). This hides stored data from external sources not normally accessible to the user.range
argument, e.g. Range = "Sheet2!A2:B7"
. If this and the sheets
argument are given, this is preferred.NA
.as_tibble
and .name_repair
as arguments. If as_tibble
is true, outputs as a tibble using tibble::as_tibble()
passing on .name_repair
(default being "check_unique"
).read_fods()
, list_fods_sheets()
, get_num_sheets_in_fods()
. These work the same way as their analogue ODS functions. The extension does not need to be fods
, however they do need to conform to the OO specification.