We open the input file now twice: The first time in latin1 encoding to read
the document encoding from the preamble. This does always work, since
traditional TeX does not allow non-ASCII contents without an encoding changing
command (except for comments, but we do not need them, and using latin1 rather
than utf8 ensures that they do not produce an iconv exception, but are simply
recored with wrong characters), and we do detect the utf8 based TeX engines
XeTeX and LuaTeX as well. The second time we open the file directly with the
document encoding.
This fixes a few tex2lyx tests on OS X, since changing the encoding of an
open file steam does not work with clang on OS X. Files using more than one
encoding are still broken, but all single-encoding files are fixed now.
Changing the codecvt_facet of a file stream after the file has been opened
does not work with clang on OS X. Therefore we avoid it if possible (i. e. the
new encoding is the same as the old one).
We claim that gcc 4.x is needed in INSTALL, so it does not make sense to keep
this old stuff. Instead, I made configure output an error if gcc is too old.
This resolves a dependency of src/support/docstream.cpp on src/TexRow.cpp,
which is the wrong way round. This fixes the linking
src/tests/check_ExternalTransforms with MSVC where the linker is not clever
enough to detect that the whole otexstream class is unused.
utf8 strings, and not only if they contain encoding changes. This is
because if the output encoding was previously changed and an utf8
string is inserted in the stream, the encoding changes cannot occur.
This was not a problem until now because normal strings could not be
inserted in a odocstream, as them would have been exchanged with encoding
changes. Indeed, the SetEnc struct has only a std::string member and
outputting a std::string would be interpreted by the compiler the same
as inserting setEncoding(std::string). However, a std::string can be
inserted in an otexstream and it is better to account for this.
I wonder whether trying "os << std::string", where os is an odocstream,
should produce an error instead of actually trying to change the stream
output encoding, but this has not been a problem until now...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39944 a592a061-630c-0410-9148-cb99ea01b6c8
and not for utf8 ones. But the simple solution is to convert to a
docstring before outputting to the underlying docstream.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39930 a592a061-630c-0410-9148-cb99ea01b6c8
on the fly are only available for ucs4 encoded strings and not for utf8
ones. So, it does only work with docstrings.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39928 a592a061-630c-0410-9148-cb99ea01b6c8
This restores \input@path handling, which turns out to be necessary, as
the TEXINPUTS mechanism is not used with relative paths. It turns out
that both methods must be used, because \input@path does not work in all
cases (most notably with tikz).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39918 a592a061-630c-0410-9148-cb99ea01b6c8
counting when exporting to latex. This is done for the code comprised
between \begin{document} and \end{document}, while the preamble code
still needs manual calls to TexRow::newline() for registering new lines.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37584 a592a061-630c-0410-9148-cb99ea01b6c8
all types requiring the exact same code, as suggested by Tommaso.
This allows to simply add a single-line instantiation declaration
if there's the need of adding another type requiring the same code.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37366 a592a061-630c-0410-9148-cb99ea01b6c8
blank lines may be inadvertently output. This is achieved by using two
special iomanip-like variables (breakln and safebreakln) in the lyx::
namespace. When they are inserted in the stream, a newline is output
only if not already at the beginning of a line. The difference between
breakln and safebreakln is that, if needed, the former outputs '\n'
and the latter "%\n".
In future, the new class will also be used for counting the number of
newlines issued. Even if the infractrure for doing that is already in
place, the counting is essentially still done the old way.
There are still places in the code where the functionality of the
class could be used, most probably. ATM, it is used for InsetTabular,
InsetListings, InsetFloat, and InsetText.
The Comment and GreyedOut insets required a special treatment and a
new InsetLayout parameter (Display) has been introduced. The default
for Display is "true", meaning that the corresponding latex
environment is of "display" type, i.e., it stands on its own, whereas
"false" means that the contents appear inline with the text. The
latter is the case for both Comment and GreyedOut insets.
Mostly, the only visible effects on latex exports should be the
disappearing of some redundant % chars and the appearing/disappearing
of null {} latex groups after a comment or lyxgreyedout environments
(they are related to the presence or absence of a space immediately
after those environments), as well as the fact that math environments
are now started on their own lines.
As a last thing, only the latex code between \begin{document} and
\end{document} goes through the new class, the preamble being directly
output through odocstream, as usual.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37360 a592a061-630c-0410-9148-cb99ea01b6c8
// std::numpunct has a hardcoded dllimport in definition, but we wanna it with 32 bit
// so we can't import it and must define it but then the compiler complains.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34262 a592a061-630c-0410-9148-cb99ea01b6c8
tex2lyx woes under windows. It may also help chktex under windows
(does it works currently?)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29361 a592a061-630c-0410-9148-cb99ea01b6c8
Japanese char between math insets becomes wrong in TeX output
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@28732 a592a061-630c-0410-9148-cb99ea01b6c8
encoded using 1 or 2 bytes, but it may be prefixed by 3-byte escape sequence.
So, a single ucs4 char could need a maximum of 5 bytes. I think that it
is better to be safe than sorry...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@27645 a592a061-630c-0410-9148-cb99ea01b6c8
properly fix bugs 5216 and 5280. The best thing to do would be recognizing
at configure time a buggy iconv and #defining WORKAROUND_ICONV_BUG in
config.h, but I don't know how that could be done.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@27618 a592a061-630c-0410-9148-cb99ea01b6c8
* lib/encodings:
* src/support/docstream.h:
- JIS is not a valid iconv name. Rename to ISO-2022-JP
* src/output_latex.cpp:
- fix wrong encoding switch.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@25510 a592a061-630c-0410-9148-cb99ea01b6c8
- odocfstream: properly fix plaintext output by getting rid of ctor with std::string argument as this can be mixed up with std::ofstream(std::string) ctor where the argument is a file. UTF8 is now the default encoding.
- PreviewLoader::Impl::startLoading(): catch another potential iconv exception.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@22332 a592a061-630c-0410-9148-cb99ea01b6c8
Now support/* should have no dependencies on src/* anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21851 a592a061-630c-0410-9148-cb99ea01b6c8
* src/support/docstream.{cpp,h}:
Move insertion operator for char types from docstream.h to
docstream.cpp and compile it only when USE_WCHAR_T is not defined.
* src/support/strfwd.h:
Implement forward declarations in standard C++ way.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21513 a592a061-630c-0410-9148-cb99ea01b6c8
- consider that not only utf8, but also most cjk encodings, are multibyte encodings
(fixes bug 4012)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19076 a592a061-630c-0410-9148-cb99ea01b6c8
