On Mon, Jan 30, 2023 at 07:28:44AM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, dem 29.01.2023 um 23:32 -0500 schrieb Scott Kostyshak:
> > Compilation with system fonts and LuaTeX fails for me with the
> > Embedded
> > Object manual because of the following preamble code:
> >
> > %% Added by the
Am Sonntag, dem 29.01.2023 um 23:32 -0500 schrieb Scott Kostyshak:
> Compilation with system fonts and LuaTeX fails for me with the
> Embedded
> Object manual because of the following preamble code:
>
> %% Added by the translator
> % Correction for PDF bookmarks
> %\usepackage[dvipdfm,bookmarks=
On Sun, Jan 29, 2023 at 09:42:03AM +0100, Jürgen Spitzmüller wrote:
> Am Samstag, dem 28.01.2023 um 19:55 -0500 schrieb Scott Kostyshak:
> > Indeed that works. Does anyone have a suggestion for which font to
> > use?
>
> IPAGothic (not IPAexGothic). This one is also already used in the
> Tutorial,
Am Samstag, dem 28.01.2023 um 19:55 -0500 schrieb Scott Kostyshak:
> Indeed that works. Does anyone have a suggestion for which font to
> use?
IPAGothic (not IPAexGothic). This one is also already used in the
Tutorial, and it is a monotype font.
--
Jürgen
signature.asc
Description: This is a d
On Sat, Jan 28, 2023 at 09:16:11PM +0100, Jürgen Spitzmüller wrote:
> Am Samstag, dem 28.01.2023 um 13:46 -0500 schrieb Scott Kostyshak:
> > The above tests are the only ones failing now. To reproduce:
> >
> > 1. Open the document (e.g., ja/Customization.lyx).
> > 2. Go to Document > Settings > Fo
Am Samstag, dem 28.01.2023 um 13:46 -0500 schrieb Scott Kostyshak:
> The above tests are the only ones failing now. To reproduce:
>
> 1. Open the document (e.g., ja/Customization.lyx).
> 2. Go to Document > Settings > Fonts and check the box "Use non-TeX
> fonts". Press "OK".
> 3. Export to PDF wi
On Sat, Jan 28, 2023 at 12:53:09PM +0100, Pavel Sanda wrote:
> On Thu, Jan 26, 2023 at 11:12:46PM -0500, Scott Kostyshak wrote:
> > Thanks to Koji for all of the improvements to the Japanese documents.
> >
> > The following ctests are failing, which used to pass before. Does anyone
> > know if the
On Sat, Jan 28, 2023 at 05:21:31PM +0100, Kornel Benko wrote:
> Am Sat, 28 Jan 2023 13:46:33 +0100
> schrieb Kornel Benko :
>
> > Am Sat, 28 Jan 2023 12:53:09 +0100
> > schrieb Pavel Sanda :
> >
> > > On Thu, Jan 26, 2023 at 11:12:46PM -0500, Scott Kostyshak wrote:
> > > > Thanks to Koji for al
Am Sat, 28 Jan 2023 13:46:33 +0100
schrieb Kornel Benko :
> Am Sat, 28 Jan 2023 12:53:09 +0100
> schrieb Pavel Sanda :
>
> > On Thu, Jan 26, 2023 at 11:12:46PM -0500, Scott Kostyshak wrote:
> > > Thanks to Koji for all of the improvements to the Japanese documents.
> > >
> > > The following ct
Am Sat, 28 Jan 2023 12:53:09 +0100
schrieb Pavel Sanda :
> On Thu, Jan 26, 2023 at 11:12:46PM -0500, Scott Kostyshak wrote:
> > Thanks to Koji for all of the improvements to the Japanese documents.
> >
> > The following ctests are failing, which used to pass before. Does anyone
> > know if they f
On Thu, Jan 26, 2023 at 11:12:46PM -0500, Scott Kostyshak wrote:
> Thanks to Koji for all of the improvements to the Japanese documents.
>
> The following ctests are failing, which used to pass before. Does anyone
> know if they fail because of bugs, or if the failures are expected now?
You might
On Thursday 28 December 2006 18:43, Jean-Marc Lasgouttes wrote:
> I still think we want to translate to LaTeX macros (xml entities) the
> caracters that do not have a good match in the output charset. To be
> able to do that, I am not sure what is required, but an exception
> seems reasonable.
I a
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Currently we are doing something illegal if iconv fails
Georg> (creating a vector from two pointers, where the end is before
Georg> the start). That throws a std::bad_alloc exception in my
Georg> environment. What do we want to do? The
On Wednesday 27 December 2006 23:08, Michael Gerz wrote:
> In case of an error, we could also try to convert each character
> individually (some may survive iconv) but maybe this is too much effort
> and leads to unwanted result as well.
That would be easy to implement, but probably be slow, and i
Georg Baum schrieb:
Not only. It could also fail if somebody writes some japanese words in a
german document without changing thelanguage. Then LyX will try to convert
the hebrew characters from utf8 to latin1, and that fails of course.
Another case could be that the requested conversion is not
On Wednesday 27 December 2006 22:44, Michael Gerz wrote:
> For what reason may iconv fail? Doesn't this indicate an internal error?
Not only. It could also fail if somebody writes some japanese words in a
german document without changing thelanguage. Then LyX will try to convert
the hebrew char
Georg Baum schrieb:
Currently we are doing something illegal if iconv fails (creating a vector
from two pointers, where the end is before the start). That throws a
std::bad_alloc exception in my environment.
What do we want to do? The attached patch simply returns an empty string, but
I am not
On Wed, Dec 15, 2004 at 02:40:53PM +, Angus Leeming wrote:
> Nonetheless, the question remains. Is this the way to go, or should I
> change the FileInfo function declaration to return a lyx::size_type?
I'd prefer std::size_t.
Andre'
Jean-Marc Lasgouttes wrote:
> Lars> Do we ever use the nlink stuff? (Or is this just something I
> Lars> added for completeness?)
>
> As Angus wrote, this is used by the xforms FileDialog. However, I
> really think we should drop this stuff, which strikes me as rather
> useless...
I'm perfectly h
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
Lars> Do we ever use the nlink stuff? (Or is this just something I
Lars> added for completeness?)
>> As Angus wrote, this is used by the xforms FileDialog. However, I
>> really think we should drop this
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Do we ever use the nlink stuff? (Or is this just something I
Lars> added for completeness?)
As Angus wrote, this is used by the xforms FileDialog. However, I
really think we should drop this stuff, which strikes me as rather
us
Angus Leeming wrote:
> Proposed test to add to lyxinclude.m4:
[ snip... ]
Actually, I see that all I need add to configure.ac is:
AC_CHECK_TYPES([nlink_t])
AH_BOTTOM([
#ifndef HAVE_NLINK_T
typedef short nlink_t;
#endif
])
Nonetheless, the question remains. Is this the way to go, or should I
Angus Leeming <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>> Proposed test to add to lyxinclude.m4:
>
| [ snip... ]
>
| Actually, I see that all I need add to configure.ac is:
>
| AC_CHECK_TYPES([nlink_t])
>
| AH_BOTTOM([
>
| #ifndef HAVE_NLINK_T
| typedef short nlink_t;
| #endif
>
| ])
>
|
On Thursday 19 April 2001 17:22, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> I have thought that the templates should not really be a part of
> Lars> the document proper. the macros are only inserted into the
> Lars> document when neede
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I have thought that the templates should not really be a part of
Lars> the document proper. the macros are only inserted into the
Lars> document when needed, upson save, export etc.
They are part of the document in the sense t
Andre Poenitz <[EMAIL PROTECTED]> writes:
| ... if somebody deletes a macro _definition_ (aka "template") but still
| uses the macro somewhere in the document?
|
| Whirling through all math insets to find such situations and disallow the
| deletion is not really an option, and simply disallow th
26 matches
Mail list logo
