Re: Spell check within ERT

2014-05-28 Thread Josh Hieronymus
 Am 28.05.2014 um 01:04 schrieb Benedict Holland 
benedict.m.holl...@gmail.com:

  Before you ask, why he is still using ERT the answer is tables. I
cannot make lyx do what I want with tables and I am not going to go through
and remove each string from ert. That would make my document unreadable.
So. How do I make lyx spell check within ERT?

As a side question, what are you doing with tables that you can't get LyX
to do without resorting to ERT?

- Josh


Re: Spell check within ERT

2014-05-28 Thread Josh Hieronymus
 Am 28.05.2014 um 01:04 schrieb Benedict Holland 
benedict.m.holl...@gmail.com:

  Before you ask, why he is still using ERT the answer is tables. I
cannot make lyx do what I want with tables and I am not going to go through
and remove each string from ert. That would make my document unreadable.
So. How do I make lyx spell check within ERT?

As a side question, what are you doing with tables that you can't get LyX
to do without resorting to ERT?

- Josh


Re: Spell check within ERT

2014-05-28 Thread Josh Hieronymus
> Am 28.05.2014 um 01:04 schrieb Benedict Holland <
benedict.m.holl...@gmail.com>:
>
> > Before you ask, why he is still using ERT the answer is tables. I
cannot make lyx do what I want with tables and I am not going to go through
and remove each string from ert. That would make my document unreadable.
So. How do I make lyx spell check within ERT?

As a side question, what are you doing with tables that you can't get LyX
to do without resorting to ERT?

- Josh


Re: Sorting in Lyx

2013-11-16 Thread Josh Hieronymus
What are your source and target formats? If you're going from pure text to
pure text, you might be best served writing a small script using a language
like Python.

- Josh
On Nov 16, 2013 2:47 PM, gordon_cooper hughgord...@gmail.com wrote:

   Does Lyx have the ability to sort strings? I am working with
 some relatively large text files, over 200 lines in some cases.
 I  have been working in Linux  which can do a line by line sort
 but runs into problems when a string is longer than a single
 line.

 Thanks,
 Gordon.



Re: Sorting in Lyx

2013-11-16 Thread Josh Hieronymus
What are your source and target formats? If you're going from pure text to
pure text, you might be best served writing a small script using a language
like Python.

- Josh
On Nov 16, 2013 2:47 PM, gordon_cooper hughgord...@gmail.com wrote:

   Does Lyx have the ability to sort strings? I am working with
 some relatively large text files, over 200 lines in some cases.
 I  have been working in Linux  which can do a line by line sort
 but runs into problems when a string is longer than a single
 line.

 Thanks,
 Gordon.



Re: Sorting in Lyx

2013-11-16 Thread Josh Hieronymus
What are your source and target formats? If you're going from pure text to
pure text, you might be best served writing a small script using a language
like Python.

- Josh
On Nov 16, 2013 2:47 PM, "gordon_cooper"  wrote:

>   Does Lyx have the ability to sort strings? I am working with
> some relatively large text files, over 200 lines in some cases.
> I  have been working in Linux  which can do a line by line sort
> but runs into problems when a string is longer than a single
> line.
>
> Thanks,
> Gordon.
>


Re: request for comments on EPUB exporting

2013-09-01 Thread Josh Hieronymus

 In my opinion, language should be taken from the document settings
 since it is already a setting. I think for other fields such as author
 this should be taken from an inset defined by the module/layout. But
 this might be because I don't know anything about EPUB. Can I export
 any document in LyX to EPUB with your method? I would just export from
 the file menu? Or do I have to first add a module?


Right now, things are set up so that any document can be exported to EPUB
using the FileExport menu option without adding an extra module.


 Perhaps an extra
 EPUB fields module could be useful in which the necessary (author
 name) and optional fields are implemented with custom insets.


Is there a good way to distinguish between necessary fields and optional
fields? Also, another issue to consider is that while some fields are not
necessary insofar as EPUB validation is concerned, different distributors
might require several such fields to be provided.


  What I'd like to implement at some point:
  - optional conversion of images to SVG format
  Note: Vector-based graphics scale better than raster-based graphics,
 making
  them well-suited for electronic media.
  Note: EPUB specifications require compliant e-readers to support SVG.
  Note: Older versions of some browsers (primarily IE) don't support SVG.
  Note: Preliminary searches turn up a package named dvisvgm
  (http://www.ctan.org/pkg/dvisvgm) that converts DVI to SVG, and it's
  licensed under the GPL v3 or later.
  - ability to split large XHTML files into smaller ones
  Note: Splitting large XHTML files should boost the performance of the
  converted EPUB documents.
  - allow selection of an image for front cover artwork
  Note: Amazon requires JPEG or TIFF format for front cover artwork.

 Thanks for this information. What about EPS/PDF? What are their
 advantages/disadvantages versus SVG?


Good question. As far as EPUB is concerned, the only images that are
required to be supported by compliant e-readers are GIFs, JPEGs, PNGs, and
SVGs, so SVGs are (supposed to be) natively supported, while PDFs and EPSs
aren't necessarily supported, and are required to use a supported type as a
fallback. For HTML in general, most web browsers support SVGs (it helps
that the SVG standard is developed by the W3C), and I think that they don't
typically support EPSs. I'm not sure about to what extent web browsers
support embedded PDFs, though preliminary research suggests that most
might. Another issue with PDFs is that they serve as containers for both
vector- and raster-based information, so if they contain any raster-based
info, that portion will appear pixelated when zoomed in.


Re: Question #3: LyX and LaTeX and TeX

2013-09-01 Thread Josh Hieronymus
On Mon, Sep 2, 2013 at 1:02 AM, Alan L Tyree alanty...@gmail.com wrote:


 Ken Springer writes:

  On 9/1/13 11:06 AM, Steve Litt wrote:
  On Sun, 1 Sep 2013 08:29:23 +0200
  Liviu Andronic landronim...@gmail.com wrote:
 
  snip
 
  It sounds as if Lyx/LaTeX has a higher learning curve than I was hoping
 for.
 
  But it intrigues me.   :-)  I've got some simple help documents I want
  to create, and I want them to look as best as I can.  So, I think, in
  about a month when I'm out of work again, I'll download LaTeX and work
  with it, then get into LyX.
 FWIW, I don't agree with this. You can become productive with LyX *very*
 quickly without knowing anything about LaTeX. You can produce nice
 looking standardised documents. It's magic.


Seconded. I began using LyX to typeset assignments for a logic class back
when I still didn't have any real knowledge of LaTeX (not that my LaTeX
knowledge is all that extensive now), and things more or less just turned
out nice and well-formatted without any effort on my part.


 Of course, you will eventually want to customise. THAT is the time to
 start looking at LaTeX IMHO.

 Cheers,
 Alan

 
  Thanks to everyone for all the advice offered.


 --
 Alan L Tyree   http://www2.austlii.edu.au/~alan
 Tel:  04 2748 6206 sip:172...@iptel.org



Re: request for comments on EPUB exporting

2013-09-01 Thread Josh Hieronymus

 In my opinion, language should be taken from the document settings
 since it is already a setting. I think for other fields such as author
 this should be taken from an inset defined by the module/layout. But
 this might be because I don't know anything about EPUB. Can I export
 any document in LyX to EPUB with your method? I would just export from
 the file menu? Or do I have to first add a module?


Right now, things are set up so that any document can be exported to EPUB
using the FileExport menu option without adding an extra module.


 Perhaps an extra
 EPUB fields module could be useful in which the necessary (author
 name) and optional fields are implemented with custom insets.


Is there a good way to distinguish between necessary fields and optional
fields? Also, another issue to consider is that while some fields are not
necessary insofar as EPUB validation is concerned, different distributors
might require several such fields to be provided.


  What I'd like to implement at some point:
  - optional conversion of images to SVG format
  Note: Vector-based graphics scale better than raster-based graphics,
 making
  them well-suited for electronic media.
  Note: EPUB specifications require compliant e-readers to support SVG.
  Note: Older versions of some browsers (primarily IE) don't support SVG.
  Note: Preliminary searches turn up a package named dvisvgm
  (http://www.ctan.org/pkg/dvisvgm) that converts DVI to SVG, and it's
  licensed under the GPL v3 or later.
  - ability to split large XHTML files into smaller ones
  Note: Splitting large XHTML files should boost the performance of the
  converted EPUB documents.
  - allow selection of an image for front cover artwork
  Note: Amazon requires JPEG or TIFF format for front cover artwork.

 Thanks for this information. What about EPS/PDF? What are their
 advantages/disadvantages versus SVG?


Good question. As far as EPUB is concerned, the only images that are
required to be supported by compliant e-readers are GIFs, JPEGs, PNGs, and
SVGs, so SVGs are (supposed to be) natively supported, while PDFs and EPSs
aren't necessarily supported, and are required to use a supported type as a
fallback. For HTML in general, most web browsers support SVGs (it helps
that the SVG standard is developed by the W3C), and I think that they don't
typically support EPSs. I'm not sure about to what extent web browsers
support embedded PDFs, though preliminary research suggests that most
might. Another issue with PDFs is that they serve as containers for both
vector- and raster-based information, so if they contain any raster-based
info, that portion will appear pixelated when zoomed in.


Re: Question #3: LyX and LaTeX and TeX

2013-09-01 Thread Josh Hieronymus
On Mon, Sep 2, 2013 at 1:02 AM, Alan L Tyree alanty...@gmail.com wrote:


 Ken Springer writes:

  On 9/1/13 11:06 AM, Steve Litt wrote:
  On Sun, 1 Sep 2013 08:29:23 +0200
  Liviu Andronic landronim...@gmail.com wrote:
 
  snip
 
  It sounds as if Lyx/LaTeX has a higher learning curve than I was hoping
 for.
 
  But it intrigues me.   :-)  I've got some simple help documents I want
  to create, and I want them to look as best as I can.  So, I think, in
  about a month when I'm out of work again, I'll download LaTeX and work
  with it, then get into LyX.
 FWIW, I don't agree with this. You can become productive with LyX *very*
 quickly without knowing anything about LaTeX. You can produce nice
 looking standardised documents. It's magic.


Seconded. I began using LyX to typeset assignments for a logic class back
when I still didn't have any real knowledge of LaTeX (not that my LaTeX
knowledge is all that extensive now), and things more or less just turned
out nice and well-formatted without any effort on my part.


 Of course, you will eventually want to customise. THAT is the time to
 start looking at LaTeX IMHO.

 Cheers,
 Alan

 
  Thanks to everyone for all the advice offered.


 --
 Alan L Tyree   http://www2.austlii.edu.au/~alan
 Tel:  04 2748 6206 sip:172...@iptel.org



Re: request for comments on EPUB exporting

2013-09-01 Thread Josh Hieronymus
>
> In my opinion, language should be taken from the document settings
> since it is already a setting. I think for other fields such as author
> this should be taken from an inset defined by the module/layout. But
> this might be because I don't know anything about EPUB. Can I export
> any document in LyX to EPUB with your method? I would just export from
> the file menu? Or do I have to first add a module?


Right now, things are set up so that any document can be exported to EPUB
using the File>Export menu option without adding an extra module.


> Perhaps an extra
> "EPUB fields" module could be useful in which the necessary (author
> name) and optional fields are implemented with custom insets.
>

Is there a good way to distinguish between necessary fields and optional
fields? Also, another issue to consider is that while some fields are not
necessary insofar as EPUB validation is concerned, different distributors
might require several such fields to be provided.


> > What I'd like to implement at some point:
> > - optional conversion of images to SVG format
> > Note: Vector-based graphics scale better than raster-based graphics,
> making
> > them well-suited for electronic media.
> > Note: EPUB specifications require compliant e-readers to support SVG.
> > Note: Older versions of some browsers (primarily IE) don't support SVG.
> > Note: Preliminary searches turn up a package named dvisvgm
> > (http://www.ctan.org/pkg/dvisvgm) that converts DVI to SVG, and it's
> > licensed under the GPL v3 or later.
> > - ability to split large XHTML files into smaller ones
> > Note: Splitting large XHTML files should boost the performance of the
> > converted EPUB documents.
> > - allow selection of an image for front cover artwork
> > Note: Amazon requires JPEG or TIFF format for front cover artwork.
>
> Thanks for this information. What about EPS/PDF? What are their
> advantages/disadvantages versus SVG?
>

Good question. As far as EPUB is concerned, the only images that are
required to be supported by compliant e-readers are GIFs, JPEGs, PNGs, and
SVGs, so SVGs are (supposed to be) natively supported, while PDFs and EPSs
aren't necessarily supported, and are required to use a supported type as a
fallback. For HTML in general, most web browsers support SVGs (it helps
that the SVG standard is developed by the W3C), and I think that they don't
typically support EPSs. I'm not sure about to what extent web browsers
support embedded PDFs, though preliminary research suggests that most
might. Another issue with PDFs is that they serve as containers for both
vector- and raster-based information, so if they contain any raster-based
info, that portion will appear pixelated when zoomed in.


Re: Question #3: LyX and LaTeX and TeX

2013-09-01 Thread Josh Hieronymus
On Mon, Sep 2, 2013 at 1:02 AM, Alan L Tyree  wrote:

>
> Ken Springer writes:
>
> > On 9/1/13 11:06 AM, Steve Litt wrote:
> >> On Sun, 1 Sep 2013 08:29:23 +0200
> >> Liviu Andronic  wrote:
> >
> > 
> >
> > It sounds as if Lyx/LaTeX has a higher learning curve than I was hoping
> for.
> >
> > But it intrigues me.   :-)  I've got some simple help documents I want
> > to create, and I want them to look as best as I can.  So, I think, in
> > about a month when I'm out of work again, I'll download LaTeX and work
> > with it, then get into LyX.
> FWIW, I don't agree with this. You can become productive with LyX *very*
> quickly without knowing anything about LaTeX. You can produce nice
> looking standardised documents. It's magic.
>

Seconded. I began using LyX to typeset assignments for a logic class back
when I still didn't have any real knowledge of LaTeX (not that my LaTeX
knowledge is all that extensive now), and things more or less just turned
out nice and well-formatted without any effort on my part.


> Of course, you will eventually want to customise. THAT is the time to
> start looking at LaTeX IMHO.
>
> Cheers,
> Alan
>
> >
> > Thanks to everyone for all the advice offered.
>
>
> --
> Alan L Tyree   http://www2.austlii.edu.au/~alan
> Tel:  04 2748 6206 sip:172...@iptel.org
>


request for comments on EPUB exporting

2013-08-30 Thread Josh Hieronymus
Hi everyone,

I'm working on exporting LyX documents to EPUB as part of my Google Summer
of Code project, and I'd like to invite you to try out my current
implementation, which can be found in the epub/master branch of the gsoc
repository (g...@git.lyx.org:gsoc.git). The export process begins by
exporting the document to XHTML via LyXHTML, then converting the XHTML to
EPUB with the scripts in lib/scripts/epub.

Right now, documents will successfully export to EPUB 2.0.1, with the
following caveats:
- Almost all metadata fields (author, book id, etc.) are filled in with
default values. Only the title field is taken from the XHTML file from
which the EPUB is converted.
- No intra-document navigation is implemented; the document is just one
long page.
- MathML isn't part of the EPUB 2.0.1 standard, so the document output
settings should be set to output math as images.

What I'd like to implement soon:
- Extracting other metadata fields from the document. The required fields
are language, title, and identifier. The title field is taken from the
document, but not  the language or the identifier. I'm taking the title
from the first paragraph to use the title inset, but there aren't
corresponding insets for the other elements, so I'm not sure of the best
way or ways to get the rest of the info. (There's an inset for author, but
the author name is needed in both reading order and file-as order, and
there's only one author inset.) One thought is to create custom insets, and
another is to ask for the information via the document settings.
- Intra-document navigation. In order to skip around within the document,
add bookmarks, etc., navigation information needs to be added to the
toc.ncx file within the EPUB archive. Which locations in the document
should be added to the list of navigable points is not obvious. First, I
read (here at http://www.gbenthien.net/Kindle%20and%20EPUB/ncx.html) that
some e-readers only work with at most one depth level--only parts, or only
chapters, or only sections, or whatever. I'm not sure whether this is
correct or not. Either way, we can't always assume what depth the user
wants in the table of contents--this is probably something we should ask.
It's probably easiest to pull the navigation info straight from the
document's table of contents, but I don't know if this info is available in
the exported XHTML file without appearing visibly.

What I'd like to implement at some point:
- optional conversion of images to SVG format
Note: Vector-based graphics scale better than raster-based graphics, making
them well-suited for electronic media.
Note: EPUB specifications require compliant e-readers to support SVG.
Note: Older versions of some browsers (primarily IE) don't support SVG.
Note: Preliminary searches turn up a package named dvisvgm (
http://www.ctan.org/pkg/dvisvgm) that converts DVI to SVG, and it's
licensed under the GPL v3 or later.
- ability to split large XHTML files into smaller ones
Note: Splitting large XHTML files should boost the performance of the
converted EPUB documents.
- allow selection of an image for front cover artwork
Note: Amazon requires JPEG or TIFF format for front cover artwork.

I'd love to hear any thoughts, comments, and suggestions you all have,
especially if you encounter any bugs or see something important I'm
overlooking.

Thanks,
Josh


request for comments on EPUB exporting

2013-08-30 Thread Josh Hieronymus
Hi everyone,

I'm working on exporting LyX documents to EPUB as part of my Google Summer
of Code project, and I'd like to invite you to try out my current
implementation, which can be found in the epub/master branch of the gsoc
repository (g...@git.lyx.org:gsoc.git). The export process begins by
exporting the document to XHTML via LyXHTML, then converting the XHTML to
EPUB with the scripts in lib/scripts/epub.

Right now, documents will successfully export to EPUB 2.0.1, with the
following caveats:
- Almost all metadata fields (author, book id, etc.) are filled in with
default values. Only the title field is taken from the XHTML file from
which the EPUB is converted.
- No intra-document navigation is implemented; the document is just one
long page.
- MathML isn't part of the EPUB 2.0.1 standard, so the document output
settings should be set to output math as images.

What I'd like to implement soon:
- Extracting other metadata fields from the document. The required fields
are language, title, and identifier. The title field is taken from the
document, but not  the language or the identifier. I'm taking the title
from the first paragraph to use the title inset, but there aren't
corresponding insets for the other elements, so I'm not sure of the best
way or ways to get the rest of the info. (There's an inset for author, but
the author name is needed in both reading order and file-as order, and
there's only one author inset.) One thought is to create custom insets, and
another is to ask for the information via the document settings.
- Intra-document navigation. In order to skip around within the document,
add bookmarks, etc., navigation information needs to be added to the
toc.ncx file within the EPUB archive. Which locations in the document
should be added to the list of navigable points is not obvious. First, I
read (here at http://www.gbenthien.net/Kindle%20and%20EPUB/ncx.html) that
some e-readers only work with at most one depth level--only parts, or only
chapters, or only sections, or whatever. I'm not sure whether this is
correct or not. Either way, we can't always assume what depth the user
wants in the table of contents--this is probably something we should ask.
It's probably easiest to pull the navigation info straight from the
document's table of contents, but I don't know if this info is available in
the exported XHTML file without appearing visibly.

What I'd like to implement at some point:
- optional conversion of images to SVG format
Note: Vector-based graphics scale better than raster-based graphics, making
them well-suited for electronic media.
Note: EPUB specifications require compliant e-readers to support SVG.
Note: Older versions of some browsers (primarily IE) don't support SVG.
Note: Preliminary searches turn up a package named dvisvgm (
http://www.ctan.org/pkg/dvisvgm) that converts DVI to SVG, and it's
licensed under the GPL v3 or later.
- ability to split large XHTML files into smaller ones
Note: Splitting large XHTML files should boost the performance of the
converted EPUB documents.
- allow selection of an image for front cover artwork
Note: Amazon requires JPEG or TIFF format for front cover artwork.

I'd love to hear any thoughts, comments, and suggestions you all have,
especially if you encounter any bugs or see something important I'm
overlooking.

Thanks,
Josh


request for comments on EPUB exporting

2013-08-30 Thread Josh Hieronymus
Hi everyone,

I'm working on exporting LyX documents to EPUB as part of my Google Summer
of Code project, and I'd like to invite you to try out my current
implementation, which can be found in the "epub/master" branch of the gsoc
repository (g...@git.lyx.org:gsoc.git). The export process begins by
exporting the document to XHTML via LyXHTML, then converting the XHTML to
EPUB with the scripts in lib/scripts/epub.

Right now, documents will successfully export to EPUB 2.0.1, with the
following caveats:
- Almost all metadata fields (author, book id, etc.) are filled in with
default values. Only the title field is taken from the XHTML file from
which the EPUB is converted.
- No intra-document navigation is implemented; the document is just one
long page.
- MathML isn't part of the EPUB 2.0.1 standard, so the document output
settings should be set to output math as images.

What I'd like to implement soon:
- Extracting other metadata fields from the document. The required fields
are language, title, and identifier. The title field is taken from the
document, but not  the language or the identifier. I'm taking the title
from the first paragraph to use the "title" inset, but there aren't
corresponding insets for the other elements, so I'm not sure of the best
way or ways to get the rest of the info. (There's an inset for author, but
the author name is needed in both reading order and "file-as" order, and
there's only one author inset.) One thought is to create custom insets, and
another is to ask for the information via the document settings.
- Intra-document navigation. In order to skip around within the document,
add bookmarks, etc., navigation information needs to be added to the
toc.ncx file within the EPUB archive. Which locations in the document
should be added to the list of navigable points is not obvious. First, I
read (here at http://www.gbenthien.net/Kindle%20and%20EPUB/ncx.html) that
some e-readers only work with at most one depth level--only parts, or only
chapters, or only sections, or whatever. I'm not sure whether this is
correct or not. Either way, we can't always assume what depth the user
wants in the table of contents--this is probably something we should ask.
It's probably easiest to pull the navigation info straight from the
document's table of contents, but I don't know if this info is available in
the exported XHTML file without appearing visibly.

What I'd like to implement at some point:
- optional conversion of images to SVG format
Note: Vector-based graphics scale better than raster-based graphics, making
them well-suited for electronic media.
Note: EPUB specifications require compliant e-readers to support SVG.
Note: Older versions of some browsers (primarily IE) don't support SVG.
Note: Preliminary searches turn up a package named dvisvgm (
http://www.ctan.org/pkg/dvisvgm) that converts DVI to SVG, and it's
licensed under the GPL v3 or later.
- ability to split large XHTML files into smaller ones
Note: Splitting large XHTML files should boost the performance of the
converted EPUB documents.
- allow selection of an image for front cover artwork
Note: Amazon requires JPEG or TIFF format for front cover artwork.

I'd love to hear any thoughts, comments, and suggestions you all have,
especially if you encounter any bugs or see something important I'm
overlooking.

Thanks,
Josh


Re: Logical Operators

2013-08-08 Thread Josh Hieronymus
They're located with the Miscellaneous symbols that appear when you click
the upside-down nabla triangle button. Or, within a math environment, you
can simply type \forall and \exists to get these symbols.
- Josh


On Thu, Aug 8, 2013 at 6:03 AM, Jens-D. Doll 
jens.d...@studium.uni-hamburg.de wrote:


 Does anyone know, where the forall and exists quantors can be found? I
 found a lot of mathematical symbols, but not these two.

 Greetings,
 Jens





Re: Logical Operators

2013-08-08 Thread Josh Hieronymus
They're located with the Miscellaneous symbols that appear when you click
the upside-down nabla triangle button. Or, within a math environment, you
can simply type \forall and \exists to get these symbols.
- Josh


On Thu, Aug 8, 2013 at 6:03 AM, Jens-D. Doll 
jens.d...@studium.uni-hamburg.de wrote:


 Does anyone know, where the forall and exists quantors can be found? I
 found a lot of mathematical symbols, but not these two.

 Greetings,
 Jens





Re: Logical Operators

2013-08-08 Thread Josh Hieronymus
They're located with the "Miscellaneous" symbols that appear when you click
the upside-down "nabla" triangle button. Or, within a math environment, you
can simply type "\forall" and "\exists" to get these symbols.
- Josh


On Thu, Aug 8, 2013 at 6:03 AM, Jens-D. Doll <
jens.d...@studium.uni-hamburg.de> wrote:

>
> Does anyone know, where the forall and exists quantors can be found? I
> found a lot of mathematical symbols, but not these two.
>
> Greetings,
> Jens
>
>
>


looking for XHTML export bugs for Google Summer of Code project

2013-07-12 Thread Josh Hieronymus
Hi everyone,

My name is Josh Hieronymus, and I'm participating in the Google Summer of
Code this year with LyX. My project is to improve LyX's XHTML export
capabilities and to implement ePub exporting as well. I've been working on
fixing XHTML export bugs that either I've found or were listed in the LyX
Bug Tracker (http://www.lyx.org/trac/wiki/BugTrackerHome). I'd like to ask
you all to let me know if you've encountered any additional bugs or issues
with XHTML exporting, either by replying to this thread or, ideally, filing
a bug report to the bug tracker. I'd really appreciate it!

Thank you,
Josh


looking for XHTML export bugs for Google Summer of Code project

2013-07-12 Thread Josh Hieronymus
Hi everyone,

My name is Josh Hieronymus, and I'm participating in the Google Summer of
Code this year with LyX. My project is to improve LyX's XHTML export
capabilities and to implement ePub exporting as well. I've been working on
fixing XHTML export bugs that either I've found or were listed in the LyX
Bug Tracker (http://www.lyx.org/trac/wiki/BugTrackerHome). I'd like to ask
you all to let me know if you've encountered any additional bugs or issues
with XHTML exporting, either by replying to this thread or, ideally, filing
a bug report to the bug tracker. I'd really appreciate it!

Thank you,
Josh


looking for XHTML export bugs for Google Summer of Code project

2013-07-12 Thread Josh Hieronymus
Hi everyone,

My name is Josh Hieronymus, and I'm participating in the Google Summer of
Code this year with LyX. My project is to improve LyX's XHTML export
capabilities and to implement ePub exporting as well. I've been working on
fixing XHTML export bugs that either I've found or were listed in the LyX
Bug Tracker (http://www.lyx.org/trac/wiki/BugTrackerHome). I'd like to ask
you all to let me know if you've encountered any additional bugs or issues
with XHTML exporting, either by replying to this thread or, ideally, filing
a bug report to the bug tracker. I'd really appreciate it!

Thank you,
Josh