Re: Spell check within ERT
> 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
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: Question #3: LyX and LaTeX and TeX
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 >
Re: request for comments on EPUB exporting
> > 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.
request for comments on EPUB exporting
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
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
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
