mactextoolbox-talk Mailing List for Mac TeX Toolbox (Page 3)
Status: Planning
Brought to you by:
jlaurens
Menu
▾
▴
mactextoolbox-talk — Discussion for Macintosh developers for TeX Tools
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(81) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Will R. <wi...@gu...> - 2005-07-05 23:09:48
|
On 6 Jul 2005, at 8:26 AM, Maxwell, Adam R wrote:
> And this is one of the reasons we use OS X, right? BTW, one of the =20=
> reasons we want to get BibDesk away from using BibTeX as a storage =20
> format is that PDF files and such can be linked as aliases, so =20
> renaming and moving them outside the app is transparent.
What would this mean? That when you saved a BibDesk document, it =20
would automatically export from its own fancy doc format to .bib in =20
the same breath? I guess that's transparent enough...
>>> Why put the name of the master file in the slaves if TeX doesn't =20
>>> need it (or maybe it does...I'm not much of a TeXpert)?
>>
>> So that when you open up the chapter file you're working on that =20
>> doesn't have anything but document text, you can still hit =20
>> "Typeset" and have something come out :)
>
> Right, but is that specific to the front end, or does TeX itself =20
> use that info? I use iTeXMac's projects to define a master file, =20
> so I've not explored putting this stuff in the file.
Oh, sorry, I though you were asking about the utility of the =20
metadata, not where it's put.
>>> I think XeTeX accepts either UTF-16 or UTF-8. Also, trying to =20
>>> read Latin 1 files in as UTF-8 will cause an error in Cocoa, and =20
>>> you get nothing back (although this is arguably better than the =20
>>> corruption you get when reading MacOSRoman as UTF-8 or something).
>>
>> In that case, it sounds like a "checksum" string at the end of the =20=
>> document that is unique for each encoding (is this even possible?) =20=
>> is the only way to do it if the information is going to be kept in-=20=
>> file.
>
> Not sure if that's possible; you're thinking of something along the =20=
> lines of the Unicode BOM?. Apple and Omni Group both have tools =20
> for sniffing text encoding, but it's a pretty dodgy business at best.
I guess I was thinking along the lines of writing a string like
abcABC=E9=EE=FC=F8=E7...
at the very end of the document, and depending what encoding the file =20=
is, this would be represented as a different stream of bytes. I would =20=
be surprised if it works, however, since the encodings map to =20
different character sets so you wouldn't be able to write the same =20
string in each of them. Oops.
Will
|
|
From: Maxwell, A. R <ada...@pn...> - 2005-07-05 22:56:46
|
On Jul 5, 2005, at 15:19, Will Robertson wrote: > On 6 Jul 2005, at 7:03 AM, Maxwell, Adam R wrote: > > >> If you store aliases as data in a plist, though (BDAlias is handy >> for this), renaming isn't a problem for the front-end specific info. >> > > Ooo, that sounds much nicer than hard coded links at the top of the > document...(even if they are relative) To quote Jon Guyer, earlier in this thread: "Aliases are such a vastly superior technology to unix symbolic links that it's not even funny." And this is one of the reasons we use OS X, right? BTW, one of the reasons we want to get BibDesk away from using BibTeX as a storage format is that PDF files and such can be linked as aliases, so renaming and moving them outside the app is transparent. > > >> Why put the name of the master file in the slaves if TeX doesn't >> need it (or maybe it does...I'm not much of a TeXpert)? >> > > So that when you open up the chapter file you're working on that > doesn't have anything but document text, you can still hit > "Typeset" and have something come out :) Right, but is that specific to the front end, or does TeX itself use that info? I use iTeXMac's projects to define a master file, so I've not explored putting this stuff in the file. > > >> I think XeTeX accepts either UTF-16 or UTF-8. Also, trying to >> read Latin 1 files in as UTF-8 will cause an error in Cocoa, and >> you get nothing back (although this is arguably better than the >> corruption you get when reading MacOSRoman as UTF-8 or something). >> > > In that case, it sounds like a "checksum" string at the end of the > document that is unique for each encoding (is this even possible?) > is the only way to do it if the information is going to be kept in- > file. Not sure if that's possible; you're thinking of something along the lines of the Unicode BOM?. Apple and Omni Group both have tools for sniffing text encoding, but it's a pretty dodgy business at best. Adam |
|
From: Will R. <wi...@gu...> - 2005-07-05 22:19:47
|
On 6 Jul 2005, at 7:03 AM, Maxwell, Adam R wrote: > If you store aliases as data in a plist, though (BDAlias is handy > for this), renaming isn't a problem for the front-end specific info. Ooo, that sounds much nicer than hard coded links at the top of the document...(even if they are relative) > Why put the name of the master file in the slaves if TeX doesn't > need it (or maybe it does...I'm not much of a TeXpert)? So that when you open up the chapter file you're working on that doesn't have anything but document text, you can still hit "Typeset" and have something come out :) > I think XeTeX accepts either UTF-16 or UTF-8. Also, trying to read > Latin 1 files in as UTF-8 will cause an error in Cocoa, and you get > nothing back (although this is arguably better than the corruption > you get when reading MacOSRoman as UTF-8 or something). In that case, it sounds like a "checksum" string at the end of the document that is unique for each encoding (is this even possible?) is the only way to do it if the information is going to be kept in-file. Will |
|
From: Maxwell, A. R <ada...@pn...> - 2005-07-05 21:33:25
|
On Jul 5, 2005, at 13:39, Maarten Sneep wrote: > On 4 Jul 2005, at 12:23, J=E9r=F4me Laurens wrote: > > >> For example, if you put the master file name of a tex source file =20 >> at the end of the source file (like emacs does), it will be hard =20 >> coded in each slave file. >> When you change the master file (what we are going to need for =20 >> efficiency) you will have to change that information in each slave =20= >> file concerned... Not very efficient. >> > > Why would you want to change the name of the master file? I don't =20 > get the example you give here - since the slave-files are stored in =20= > the master file, and their relative location is fixed through the =20 > \input statement (or format specific alternatives). So _moving_ the =20= > master is not an option, and renaming (IMHO) is a relatively rare =20 > action. Inefficiency is unimportant for such cases. If you store aliases as data in a plist, though (BDAlias is handy for =20= this), renaming isn't a problem for the front-end specific info. Why =20= put the name of the master file in the slaves if TeX doesn't need it =20 (or maybe it does...I'm not much of a TeXpert)? > >> Another big problem concerning metadata in the source deals with =20 >> the encoding. >> The encoding is meant to deal with the text only, but it will =20 >> naturally apply to the metadata too. >> People using marks would want to use utf16 because it fits their =20 >> natural language and they feel far more comfortable with that (the =20= >> same for tex comments). For more general metadata, some frontends =20 >> might want to store pure binary metadata... But if the metadata =20 >> are embedded, those things will be forbidden. >> > > Last time I checked there were no TeX engines that accepted utf-16. =20= > Since utf-8 is a strict superset of ASCII, I don't think there is a =20= > problem, especially since both uft versions can encode the same =20 > information. I think XeTeX accepts either UTF-16 or UTF-8. Also, trying to read =20 Latin 1 files in as UTF-8 will cause an error in Cocoa, and you get =20 nothing back (although this is arguably better than the corruption =20 you get when reading MacOSRoman as UTF-8 or something). > > And for pure binary metadata: I ran away from word to get rid of =20 > binary files, so if a special project file needs to be added, let =20 > it be an xml file - or something else BBEdit can handle. You can archive binary data such as aliases and put it in an XML =20 file, which is how OS X apps store their "Recent Files" lists in a =20 property list. It doesn't really matter if the file is XML or =20 binary, as long as it's an open standard. [...] > > >>> On the other hand, if there are other standards that spring up =20 >>> for storing the encoding of the file in an extended attribute -- =20 >>> well, we may as well use that as well! (too many `well's) >>> >>> I am more interested with the possibilities raised from a rich =20 >>> document interface, and I think WHERE the metadata is stored is =20 >>> less of an issue -- it can always be changed if a new method =20 >>> turns out to be better. >>> >> >> My opinion is the following: >> >> We have 3 locations to save metadata attributes >> >> 1 - inside the source file, like emacs does >> 2 - in an external file at a definite location relative to the =20 >> source file, like resource forks and the TeX Wrapper Structure I =20 >> presented in EuroTeX 2005 >> 3 - in an external file at a definite location, relative to the =20 >> application, like BBEdit and TextWrangler do, like unix app do in =20 >> their .cshrc and alike... >> >> 3 is not portable. >> Moreover, I am wondering why BBEdit put this 15 days limit... May =20 >> be they had a structural reason that prohibits an intense use of =20 >> this design... >> > > About 313 entries and counting. There are some types of metadata =20 > you do not want to inherit from coworkers, while keeping them for =20 > your own sessions: window locations come to mind (especially if you =20= > have a 12" powerbook, and the colleague has a 30" display). I think =20= > you are too quick in discounting the private option for (some =20 > types) of metadata. And I don't want window settings from my work machine transferred to =20 my home machine, for the reason you mention. This sort of =20 information belongs in user defaults or some cache file, as BBEdit =20 does. I don't care about the window settings for the readme file =20 that I opened up 6 months ago and then trashed... > > >> So only 1 and 2 remain, and no choice should be made between them: =20= >> they are different and will serve different purposes, we need both. >> >> For point 1, marks and collapsing region bounds are the only kind =20 >> of informations that really need to be stored inside the source. >> > > With the marks I agree, with the collapsing region bounds, I'm not =20 > too sure: they may be a personal preference, not shared between =20 > collaborators. This information can be stored outside the source =20 > file (in some project file, which can contain the lot in a TeX =20 > wrapper - however they may look*). I think this is the sort of thing Xcode stores in it's project =20 bundles, although I haven't looked closely. A wrapper seems like a =20 reasonable location for this since you might want the same settings =20 at all locations, but I'd expect it to be at least on a per-user basis. >> Moreover, in a very near future, it will not be strange to use an =20 >> XML input instead of the standard tex input. >> > > The engine underneath is still likely to be TeX - and for the =20 > foreseeable future that means utf-8 input, not utf-16 or utf-32, =20 > but that is a minor remark here. It does mean that at the very =20 > least for now we can store the text encoding in the file itself, =20 > and for XML there are official options, also in-file. XeTeX might be an exception to this, as previously noted, so storing =20 encoding in the file might be practi=13ca=13ble for a shorter time than = =20 we realize. > > >> If we want to store the same metadata in the source file, we will =20 >> have to design another mean for that purpose. >> > > XML files can contain comments as well, no real need to change =20 > anything here, if at least we keep this in the back of our minds. =20 > OTOH, xml may require such a different editor because of the =20 > verbosity-level, that keeping it in hte back of our minds is way =20 > too much honour. Not that it's relevant, but I use LaTeX at least partly because I =20 think editing XML sucks. If Mike had chosen an XML format for =20 BibDesk's help, I'd probably conveniently forget to ever add to it. --=20 Adam= |
|
From: Maarten S. <maa...@xs...> - 2005-07-05 20:40:06
|
On 4 Jul 2005, at 12:23, J=E9r=F4me Laurens wrote: > Le 3 juil. 05, =E0 02:16, Will Robertson a =E9crit : > >> I honestly have no problem, for now, with implementing metadata in =20= >> the same way as emacs: in a big comment block at the very end of =20 >> the document. It would be easy to hide from the user, and is very =20 >> portable. > > Yes, but not all metadata data should fit there. > And this is can be closed design. Any design can be closed, but I have a hard time seeing an in-file =20 comment-tag, plain to see for all, and even with documentation - if =20 you pester an emacs adept long enough for it - as a closed design. > For example, if you put the master file name of a tex source file =20 > at the end of the source file (like emacs does), it will be hard =20 > coded in each slave file. > When you change the master file (what we are going to need for =20 > efficiency) you will have to change that information in each slave =20 > file concerned... Not very efficient. Why would you want to change the name of the master file? I don't get =20= the example you give here - since the slave-files are stored in the =20 master file, and their relative location is fixed through the \input =20 statement (or format specific alternatives). So _moving_ the master =20 is not an option, and renaming (IMHO) is a relatively rare action. =20 Inefficiency is unimportant for such cases. > So you need to embed only a reference to the location where the =20 > master information is stored, such that the reference never =20 > changes, but the information it points to can. That way, you just =20 > have to change the master name in one location, and all the slave =20 > files will be linked to that info automatically. This is some kind =20 > of aliasing. The best policy is to put nothing in the source file. I don't get this: how is putting the information in another file =20 solving something? The slave files need to reference something, or =20 else: how are you going to pick this reference up when someone opens =20 a random tex file - that turns out to be some slave file. > Another big problem concerning metadata in the source deals with =20 > the encoding. > The encoding is meant to deal with the text only, but it will =20 > naturally apply to the metadata too. > People using marks would want to use utf16 because it fits their =20 > natural language and they feel far more comfortable with that (the =20 > same for tex comments). For more general metadata, some frontends =20 > might want to store pure binary metadata... But if the metadata are =20= > embedded, those things will be forbidden. Last time I checked there were no TeX engines that accepted utf-16. =20 Since utf-8 is a strict superset of ASCII, I don't think there is a =20 problem, especially since both uft versions can encode the same =20 information. And for pure binary metadata: I ran away from word to get rid of =20 binary files, so if a special project file needs to be added, let it =20 be an xml file - or something else BBEdit can handle. >> On the other hand, if there are other standards that spring up for =20= >> storing the encoding of the file in an extended attribute -- well, =20= >> we may as well use that as well! (too many `well's) >> >> I am more interested with the possibilities raised from a rich =20 >> document interface, and I think WHERE the metadata is stored is =20 >> less of an issue -- it can always be changed if a new method turns =20= >> out to be better. > > My opinion is the following: > > We have 3 locations to save metadata attributes > > 1 - inside the source file, like emacs does > 2 - in an external file at a definite location relative to the =20 > source file, like resource forks and the TeX Wrapper Structure I =20 > presented in EuroTeX 2005 > 3 - in an external file at a definite location, relative to the =20 > application, like BBEdit and TextWrangler do, like unix app do in =20 > their .cshrc and alike... > > 3 is not portable. > Moreover, I am wondering why BBEdit put this 15 days limit... May =20 > be they had a structural reason that prohibits an intense use of =20 > this design... About 313 entries and counting. There are some types of metadata you =20 do not want to inherit from coworkers, while keeping them for your =20 own sessions: window locations come to mind (especially if you have a =20= 12" powerbook, and the colleague has a 30" display). I think you are =20 too quick in discounting the private option for (some types) of =20 metadata. > So only 1 and 2 remain, and no choice should be made between them: =20 > they are different and will serve different purposes, we need both. > > For point 1, marks and collapsing region bounds are the only kind =20 > of informations that really need to be stored inside the source. With the marks I agree, with the collapsing region bounds, I'm not =20 too sure: they may be a personal preference, not shared between =20 collaborators. This information can be stored outside the source file =20= (in some project file, which can contain the lot in a TeX wrapper - =20 however they may look*). > Moreover, in a very near future, it will not be strange to use an =20 > XML input instead of the standard tex input. The engine underneath is still likely to be TeX - and for the =20 foreseeable future that means utf-8 input, not utf-16 or utf-32, but =20 that is a minor remark here. It does mean that at the very least for =20 now we can store the text encoding in the file itself, and for XML =20 there are official options, also in-file. > If we want to store the same metadata in the source file, we will =20 > have to design another mean for that purpose. XML files can contain comments as well, no real need to change =20 anything here, if at least we keep this in the back of our minds. =20 OTOH, xml may require such a different editor because of the =20 verbosity-level, that keeping it in hte back of our minds is way too =20 much honour. > If the same metadata were saved in an external location, the format =20= > of the storage would not suffer the adoption of xml for input =20 > files, and no extra work would be necessary. The description of where the different points are inserted - if _all_ =20= metadata is expelled from the source files to some external storage - =20= may very well need to change, from a line-count to a node count. > Finally 1 -and- 2 are the only choice. Now, the problem is to =20 > define what kind of meta information should be stored and where. I still think there is a place for 3, but you're right in stating =20 that the really interesting question is what should be stored. loc description =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1,2 text encoding (extended attribute, in-file, project file) 1 markers (in file - easiest, most robust) 3 window location (private use only) 1,2 master file (extended attribute, in-file, project file) . . . I think we can make the list way longer, and please do so. We'll =20 scratch items from this list later on, and determine precedence =20 preferences (if stored in multiple locations, which one takes =20 precedence in case of conflict?). Maarten= |
|
From: Will R. <wi...@gu...> - 2005-07-04 22:27:42
|
On 4 Jul 2005, at 9:10 PM, J=E9r=F4me Laurens wrote: > > Guess what, I have my own log parser in iTeXMac since a decade... > TeXnicenter also has a log parser and the same for auctex... > As far as I known, auctex technology should be of great help if =20 > anyone can understand the source code... :) Yeah, I know iTeXMac does some nice stuff. I just really liked the approach taken by LaTeXiT. I think there's still room for improvement in all approaches. Will= |
|
From: <jer...@u-...> - 2005-07-04 11:42:38
|
Le 4 juil. 05, =E0 10:05, Will Robertson a =E9crit : > Hi Pierre, > > [...] > On 3 Jul 2005, at 7:30 PM, Pierre Chatelier wrote: > >>> [in the error manager] so if it could be reliably determine what the=20= >>> offending token is it would be nice to see that as well. >> For now, I would prefer not to. I prefer to be less precise, but=20 >> ensure that the error-line is ok, rather than trying to deduce the=20 >> faulty token, with the risk of getting wrong and give a bad=20 >> indication. However, since LaTeXiT is open source and will be a=20 >> toolbox project, if anybody has the knowledge to improve that, this=20= >> will be no problem I think. Do you agree with this opinion ? > > Sounds great! > A log-file parser sounds like a pretty handy tool that many front ends=20= > could use. I know Jonathan Fine was interested in such a thing a=20 > little while back on comp.text.tex... Guess what, I have my own log parser in iTeXMac since a decade... TeXnicenter also has a log parser and the same for auctex... As far as I known, auctex technology should be of great help if anyone=20= can understand the source code... pdfsync like technology would be of great help here. More seriously, there is a funny bug in latextit: start dragging the=20 output, but drop on the output pane, then play with the magnification=20 slider. The image gets fuzzy with some kind of gaussian bler... You can=20= retrieve the original output by drag n drop on itself. |
|
From: <jer...@u-...> - 2005-07-04 10:25:17
|
Le 3 juil. 05, =E0 02:16, Will Robertson a =E9crit : > On 3 Jul 2005, at 7:15 AM, Maarten Sneep wrote: >> And for metadata: >> >> % \iffalse >> %<*metadata> >> %! pragma mark My marker. >> %</metadata> >> % \fi >> >> Is this a workable suggestion? Since dtx files are processed at=20 >> different levels, I think you get more room to play with and add your=20= >> own stuff. On the other hand, Most dtx files are also pure ASCII, so=20= >> the encoding is less important, and sectioning is already rather=20 >> clearly indicated (making markers less of an issue). > > Well, personally I think that > %! pragma mark > is very ugly, but as a technique to mark dtx files I think you're=20 > right that it works well. (Note also that fontspec.dtx is a unicode=20 > document for example.) > > A mark that might be useful for editing DTX files might be > %! TODO: > I don't think there's any point in surrounding the metadata with > %<*metadata> > tags unless that information needs to be extracted from the dtx at=20 > some stage. And I can't really see why that would be... > > (On a previous note:) > > I honestly have no problem, for now, with implementing metadata in the=20= > same way as emacs: in a big comment block at the very end of the=20 > document. It would be easy to hide from the user, and is very=20 > portable. Yes, but not all metadata data should fit there. And this is can be closed design. For example, if you put the master file name of a tex source file at=20 the end of the source file (liek emacs does), it will be hard coded in=20= each slave file. When you change the master file (what we are going to need for=20 efficiency) you will have to change that information in each slave file=20= concerned... Not very efficient. So you need to embed only a reference to the location where the master=20= information is stored, such that the reference never changes, but the=20 information it points to can. That way, you just have to change the=20 master name in one location, and all the slave files will be linked to=20= that info automatically. This is some kind of aliasing. The best policy=20= is to put nothing in the source file. Another big problem concerning metadata in the source deals with the=20 encoding. The encoding is meant to deal with the text only, but it will naturally=20= apply to the metadata too. People using marks would want to use utf16 because it fits their=20 natural language and they feel far more comfortable with that (the same=20= for tex comments). For more general metadata, some frontends might want=20= to store pure binary metadata... But if the metadata are embedded,=20 those things will be forbidden. > > On the other hand, if there are other standards that spring up for=20 > storing the encoding of the file in an extended attribute -- well, we=20= > may as well use that as well! (too many `well's) > > I am more interested with the possibilities raised from a rich=20 > document interface, and I think WHERE the metadata is stored is less=20= > of an issue -- it can always be changed if a new method turns out to=20= > be better. My opinion is the following: We have 3 locations to save metadata attributes 1 - inside the source file, like emacs does 2 - in an external file at a definite location relative to the source=20 file, like resource forks and the TeX Wrapper Structure I presented in=20= EuroTeX 2005 3 - in an external file at a definite location, relative to the=20 application, like BBEdit and TextWrangler do, like unix app do in their=20= .cshrc and alike... 3 is not portable. Moreover, I am wondering why BBEdit put this 15 days limit... May be=20 they had a structural reason that prohibits an intense use of this=20 design... So only 1 and 2 remain, and no choice should be made between them: they=20= are different and will serve different purposes, we need both. For point 1, marks and collapsing region bounds are the only kind of=20 informations that really need to be stored inside the source. Moreover, in a very near future, it will not be strange to use an XML=20 input instead of the standard tex input. If we want to store the same metadata in the source file, we will have=20= to design another mean for that purpose. If the same metadata were saved in an external location, the format of=20= the storage would not suffer the adoption of xml for input files, and=20 no extra work would be necessary. Finally 1 -and- 2 are the only choice. Now, the problem is to define=20 what kind of meta information should be stored and where. |
|
From: Will R. <wi...@gu...> - 2005-07-04 08:05:55
|
Hi Pierre, Thanks for your work on this program. Is there any word from the TeXType project on their competing product? On 3 Jul 2005, at 7:30 PM, Pierre Chatelier wrote: >> [in the error manager] so if it could be reliably determine what >> the offending token is it would be nice to see that as well. > For now, I would prefer not to. I prefer to be less precise, but > ensure that the error-line is ok, rather than trying to deduce the > faulty token, with the risk of getting wrong and give a bad > indication. However, since LaTeXiT is open source and will be a > toolbox project, if anybody has the knowledge to improve that, this > will be no problem I think. Do you agree with this opinion ? Sounds great! A log-file parser sounds like a pretty handy tool that many front ends could use. I know Jonathan Fine was interested in such a thing a little while back on comp.text.tex... >> - I think I like the use of those things that look like tabs but >> are actually buttons. The old school way would be to use radio >> buttons, but I'm undecided if these things are actually better >> than radio buttons. > This thing is called a "segmented control"; it was already > available with Panther, but with Tiger, it is directly usable from > InterfaceBuilder. At the very beginning of LaTeXiT, I was using > radio buttons, because I did not know the existence of segmented > controls. A friend of mine told me about that, I and find that in > this context, it is much more beautiful. Yep, I think I like it! >> - For a future version, it'd be good to add a toolbar for the >> LaTexise > A toolbar ? For what purpose ? > >> button as well as a button for the drawer, etc. > Do you mean, to open/close the drawers ? Oh, I understand, now : > putting this buttons in the toolbar. Mmmh, it seems to me that my > toolbar would be very "poor" (only two button), so it would not be > very nice. Let's keep it in mind for later -- I think there's more that could be put in there than you think :) For the latest beta, I don't have much to say -- it's looking pretty nice to me. I would second the notion to have the margins stick, but I think you're determined to do this anyway. I would just leave them on 1pt or 1.5pt top and bottom, probably, and rarely adjust them manually. Once again, thanks! Will |
|
From: Pierre C. <pie...@cl...> - 2005-07-03 21:16:33
|
> But why the system.log error messages that I don't seem to get with > LEE? The ones that looks like: > > Jul 3 13:45:47 HSPBG4 /Applications/TeX/LaTeXiT/LaTeXiT.app/ > Contents/MacOS/LaTeXiT: WARNING: Type1 font data returned by > OFAStreamPSDownload isn't in the correct format required by the > Adobe Type 1 Font Format specification. > > Which run of pdflatex generates those? Sorry, This one is not related to pdflatex output : it appears when I am initializing a Cocoa PDFDocument with pdfdata from a file produced by pdflatex. It seems that pdf made with pdflatex is not fully pdf compliant, but in practice there seem to be no problem at all. I even hope that this warning will disappear one day, either by a Cocoa or a pdflatex upgrade. Regards, Pierre |
|
From: Herbert S. <he...@wi...> - 2005-07-03 21:09:15
|
On Jul 3, 2005, at 3:43 PM, Pierre Chatelier wrote: >> By the way, what is the difference in the way you generate the >> equation and LaTeX Equation Editor generates the equation? >> > Ok, it is rather long, but let's explain it : > ... Howdy, Understood; it's the need for baseline information that leads to the complications. > ... >> 2)The processing done by LaTeX Equation Editor doesn't produce the >> console error messages I see with LaTeXiT. I wonder if Gary Gray's >> is also llnked to those error messages in some way. >> > it seems to me that LEE and LaTeXiT produces the same error > messages, since LEE gives the full log. In latexit, it is just > filtered in some way. > >> Also, are the error messages produced while processing the >> equation through pdflatex or when attempting to display the equation? >> > the errors are get back from pdflatex output > > > Regards, > > Pierre > But why the system.log error messages that I don't seem to get with LEE? The ones that looks like: Jul 3 13:45:47 HSPBG4 /Applications/TeX/LaTeXiT/LaTeXiT.app/Contents/ MacOS/LaTeXiT: WARNING: Type1 font data returned by OFAStreamPSDownload isn't in the correct format required by the Adobe Type 1 Font Format specification. Which run of pdflatex generates those? Good Luck, Herb Schulz |
|
From: Pierre C. <pie...@cl...> - 2005-07-03 20:43:36
|
> By the way, what is the difference in the way you generate the > equation and LaTeX Equation Editor generates the equation? Ok, it is rather long, but let's explain it : LEE uses latex | dvips | epstopdf, because dvips has the ability to crop and magnify. Very handy. I found it a pity not to be able to simply use pdflatex. But Maarten introduced me about the problem of the baseline, and here will be the point. To compute the baseline, there is a magical snippet that uses boxes that automatically know their size and baseline. The problem is that it fails with multi-line equation (does not even compile). So I had to get a compromise to make everything work. Below is a copy/paste of the comment I put into LaTeXiT about that. //The principle used is the following one : // -first, we compute a very simple latex file, without cropping or magnification. If there are no syntax errors // from the user, it will be ok. Otherwise, it will be useful to report errors to the user. // -second, we must crop and magnify. There is a very fast an efficient method, using boxes that will automagically // know their size, and even compute the *baseline* (what is the baseline ? it is the line on which your equation should be // aligned to fit well inside some text. For instance, a fraction would be shifted down, thanks to a negative baseline) // The problem is that, this fast and efficient method may fail with certain kinds of equations (especially multi-lines) // So it is just a try; if it works, that's great, we keep the result. Otherwise, we will use a heavy but more robust method // -third; in case that the second step failed, there is as a last resort a heavy and robust method to compute a bounding box // (to crop), and magnify the document. We compute the bounding box by calling gs (GhostScript) on the result of the first step. // Then, we use the latex template of the second step, with the magical boxes, but its body will just be the pdf image generated // during the first step ! So it can be cropped and magnify. > 1)The processing by LaTeX Equation Editor is much faster. This > could, of course, be because of the baseline information you've got > to extract. So to be quick : there are two pdflatex calls, and there may be a third call to pdflatex and a call to gs. That's why you may experience slower speed than with LEE. You may argue that the first and the second step could be fusioned, to save one pdflatex call. But it is not possible, since in this case, there would be problems to report syntax errors to the user if he has typed multi-line equations. > 2)The processing done by LaTeX Equation Editor doesn't produce the > console error messages I see with LaTeXiT. I wonder if Gary Gray's > is also llnked to those error messages in some way. it seems to me that LEE and LaTeXiT produces the same error messages, since LEE gives the full log. In latexit, it is just filtered in some way. > Also, are the error messages produced while processing the equation > through pdflatex or when attempting to display the equation? the errors are get back from pdflatex output Regards, Pierre |
|
From: Herbert S. <he...@wi...> - 2005-07-03 20:22:36
|
On Jul 3, 2005, at 3:09 PM, Pierre Chatelier wrote: > > Ok, so it seems we can get the best of our two ways of thinking. I > want to keep the floating palette, because it si far smaller than > the preferences pane, so it can be displayed aside the document for > quick modifications. And there should be a place in the preferences > to enter default margins. > I just need your opinion about two questions: > If I change the margins in the floating palette, do you think > it should alter the preferences (I guess "no") > If I close the margin palette, should it reset the defaults ? > (I guess "yes") > Do you mind if LaTeXiT does not remember the margins used to > generate an equation ? I hope "no", because on the contrary, the > floating palette is no more the good way to present that > information (in this case, the margins should be integrated into > the document window, and so far, I failed in doing that nicely) > > > Regards, > > Pierre Howdy, I believe I agree on all points. By the way, what is the difference in the way you generate the equation and LaTeX Equation Editor generates the equation? I ask for two reasons: 1)The processing by LaTeX Equation Editor is much faster. This could, of course, be because of the baseline information you've got to extract. 2)The processing done by LaTeX Equation Editor doesn't produce the console error messages I see with LaTeXiT. I wonder if Gary Gray's is also llnked to those error messages in some way. Also, are the error messages produced while processing the equation through pdflatex or when attempting to display the equation? Good Luck, Herb Schulz (he...@wi...) |
|
From: Pierre C. <pie...@cl...> - 2005-07-03 20:09:16
|
>>> I guess I'd want the settings to stick; i.e., be a preference and
>>> then be able to override that using the pallete.
>>>
>> Mmmh.. Are you sure ? I have supposed that the use of margins was
>> rather rare, so there was no need to save that setting.
>> Moreover, I also suppose that it is not a "once-for-all" setting,
>> in the sense that if you use it, it is for a very particular case.
>> So, I chose not to put it in the preferences, since from this
>> point of view it would have no meaning, and the user would forgot
>> it (leading to unexpected behaviour)
>> By the way, the solution of a floating palette was somewhat
>> natural : if you need it, display it, and tune it. (From my point
>> of view, of course)
>> Could you be more precise on the way you are using such a feature,
>> so that I understand better your needs ?
>
> There are many glyphs that extend a tiny bit outside their defined
> boxes to look optically correct; an example would be the number 3.
> If the bounding box is made very tight pieces of these glyphs get
> cut off. Try the equation, \(\sin\,30=0.5\) (as an in-line equation
> and no extra margin and, of course, without the \( and \)) and
> you'll see that the left side of the `s' as well as the top of the
> `3' are slightly cut off. I'd like to force a 1pt margin all around
> so that I don't run into this problem as often. If the baseline
> information compensates then there should be almost not noticeable
> problem most of the time. Maybe all I need 90% of the time is 0.5pt
> but I know I can see problems when the extra margin is set to 0pt
> more often than I'd like.
Ok, so it seems we can get the best of our two ways of thinking. I
want to keep the floating palette, because it si far smaller than the
preferences pane, so it can be displayed aside the document for quick
modifications. And there should be a place in the preferences to
enter default margins.
I just need your opinion about two questions:
If I change the margins in the floating palette, do you think it
should alter the preferences (I guess "no")
If I close the margin palette, should it reset the defaults ? (I
guess "yes")
Do you mind if LaTeXiT does not remember the margins used to
generate an equation ? I hope "no", because on the contrary, the
floating palette is no more the good way to present that information
(in this case, the margins should be integrated into the document
window, and so far, I failed in doing that nicely)
Regards,
Pierre
|
|
From: Herbert S. <he...@wi...> - 2005-07-03 19:40:26
|
On Jul 3, 2005, at 2:17 PM, Pierre Chatelier wrote: >> I guess I'd want the settings to stick; i.e., be a preference and >> then be able to override that using the pallete. >> >> > Mmmh.. Are you sure ? I have supposed that the use of margins was > rather rare, so there was no need to save that setting. > Moreover, I also suppose that it is not a "once-for-all" setting, > in the sense that if you use it, it is for a very particular case. > So, I chose not to put it in the preferences, since from this point > of view it would have no meaning, and the user would forgot it > (leading to unexpected behaviour) > By the way, the solution of a floating palette was somewhat > natural : if you need it, display it, and tune it. (From my point > of view, of course) > Could you be more precise on the way you are using such a feature, > so that I understand better your needs ? > ... Howdy, There are many glyphs that extend a tiny bit outside their defined boxes to look optically correct; an example would be the number 3. If the bounding box is made very tight pieces of these glyphs get cut off. Try the equation, \(\sin\,30=0.5\) (as an in-line equation and no extra margin and, of course, without the \( and \)) and you'll see that the left side of the `s' as well as the top of the `3' are slightly cut off. I'd like to force a 1pt margin all around so that I don't run into this problem as often. If the baseline information compensates then there should be almost not noticeable problem most of the time. Maybe all I need 90% of the time is 0.5pt but I know I can see problems when the extra margin is set to 0pt more often than I'd like. Good Luck, Herb Schulz (he...@wi...) |
|
From: Pierre C. <pie...@cl...> - 2005-07-03 19:17:36
|
> I guess I'd want the settings to stick; i.e., be a preference and > then be able to override that using the pallete. > Mmmh.. Are you sure ? I have supposed that the use of margins was rather rare, so there was no need to save that setting. Moreover, I also suppose that it is not a "once-for-all" setting, in the sense that if you use it, it is for a very particular case. So, I chose not to put it in the preferences, since from this point of view it would have no meaning, and the user would forgot it (leading to unexpected behaviour) By the way, the solution of a floating palette was somewhat natural : if you need it, display it, and tune it. (From my point of view, of course) Could you be more precise on the way you are using such a feature, so that I understand better your needs ? > Also, what processing steps are you using? > just pdflatex. To alter the margins, I try to tune my use of geometry package, and the geometry of the \boxes themselves. Again, thank you very much for taking time to make that feedback Pierre |
|
From: Herbert S. <he...@wi...> - 2005-07-03 18:59:42
|
On Jul 3, 2005, at 1:53 PM, Herbert Schulz wrote: > > On Jul 3, 2005, at 10:20 AM, Pierre Chatelier wrote: > > >> >> and added a little palette to change margins (Option-command-M) >> This won't fix the example below, however, which seems to be very >> complex >> But it allows to correct occasional bounding box being too tight. >> >> > > Howdy, > > I guess I'd want the settings to stick; i.e., be a preference and > then be able to override that using the pallet. > > Also, what processing steps are you using? Are you using the > shipout of the tight box or forcing the bounding box after you > create the pdf file? Since there should only be a snippet of text > or a single (possibly multi-line displayed) equation you might try > just creating the regular pdf and running that through pdfcrop. Did > we go through this once before? > > Good Luck, > > Herb Schulz > (he...@wi...) Howdy, Ooops... I forgot about the baseline information! Good Luck, Herb Schulz (he...@wi...) |
|
From: Herbert S. <he...@wi...> - 2005-07-03 18:53:37
|
On Jul 3, 2005, at 10:20 AM, Pierre Chatelier wrote: > > and added a little palette to change margins (Option-command-M) > This won't fix the example below, however, which seems to be very > complex > But it allows to correct occasional bounding box being too tight. > Howdy, I guess I'd want the settings to stick; i.e., be a preference and then be able to override that using the pallet. Also, what processing steps are you using? Are you using the shipout of the tight box or forcing the bounding box after you create the pdf file? Since there should only be a snippet of text or a single (possibly multi-line displayed) equation you might try just creating the regular pdf and running that through pdfcrop. Did we go through this once before? Good Luck, Herb Schulz (he...@wi...) |
|
From: Pierre C. <pie...@cl...> - 2005-07-03 15:20:26
|
Hello, The download URL is still : http://ktd.club.fr/programmation/fichiers/ LaTeXiT-beta.dmg I have updated the program again thanks to your proposals : The encoding is now utf-8 $$...$$ is now \[...\] Latexis[z]e is now LaTeX it! Fixed the localization about decimal point Added an "advanced" config panel to please Aaron and added a little palette to change margins (Option-command-M) This won't fix the example below, however, which seems to be very complex But it allows to correct occasional bounding box being too tight. > \documentclass{article} > \begin{document} > \parindent=0pt > \voffset=-1in > \hoffset=-1in > \setbox0=\hbox{$1=3$} > \dimen0=\ht0 > \advance\dimen0\dp0 > \pdfpageheight=\dimen0 > \pdfpagewidth=\wd0 > \shipout\box0 > \end{document} > % (Stolen ages ago from Maarten, perhaps) Regards Pierre |
|
From: Maarten S. <maa...@xs...> - 2005-07-03 14:36:09
|
On 3 Jul 2005, at 15:22, Herbert Schulz wrote: > On Jul 3, 2005, at 8:08 AM, Maarten Sneep wrote: > >> Arrays will set normally, it is with the multi-line constructs >> from the amsmath package that the trouble really starts. > > That is what I meant too. I'd guess the multi-line environments > would have to be set at text rather than maths; i.e., use ``text'' > for full control. There are other options for multi-line equations, the preview package is one of them. >> Frankly, getting a template that would allow us to obtain >> displayed maths _and_ get the baseline offset has been a nightmare >> (and is still unresolved). May I point you to http://www.xs4all.nl/ >> ~msneep/articles/baseline.html for background information? > > I would suggest that there is little need for a baseline for > displayed equations and the offset from the lower left corner can > be (0pt,0pt) in those situations. I think it is only for in-line > equations that you run into a problem; am I correct there? No, displayed equations will be used for, well, display uses, and I think most equations for keynote will be displayed, even if more material is shown on the same line. Displayed equations look "fuller" and that is what you need in Keynote. Maarten |
|
From: Herbert S. <he...@wi...> - 2005-07-03 13:22:23
|
On Jul 3, 2005, at 8:08 AM, Maarten Sneep wrote: > > Arrays will set normally, it is with the multi-line constructs from > the amsmath package that the trouble really starts. > Howdy, That is what I meant too. I'd guess the multi-line environments would have to be set at text rather than maths; i.e., use ``text'' for full control. > Frankly, getting a template that would allow us to obtain displayed > maths _and_ get the baseline offset has been a nightmare (and is > still unresolved). May I point you to http://www.xs4all.nl/~msneep/ > articles/baseline.html for background information? > > Maarten > I would suggest that there is little need for a baseline for displayed equations and the offset from the lower left corner can be (0pt,0pt) in those situations. I think it is only for in-line equations that you run into a problem; am I correct there? Good Luck, Herb Schulz (he...@wi...) |
|
From: Herbert S. <he...@wi...> - 2005-07-03 13:13:54
|
On Jul 3, 2005, at 7:51 AM, Pierre Chatelier wrote: > In that case, I would prefer only an entry box. But so far, I > really do not see how to add this control *nicely* in the > interface. I made some tests, not very successful. If you have an > idea... > > Pierre > Howdy, I don't think it is something that needs to be changed very often so putting it somewhere in the preferences should be fine. I don't know whether it needs a separate tab there or can be fit in one of the present tabs. Good Luck, Herb Schulz (he...@wi...) |
|
From: Maarten S. <maa...@xs...> - 2005-07-03 13:09:14
|
On 3 Jul 2005, at 14:53, Herbert Schulz wrote: > Many people still use $...$ for in-line maths but a ``more LaTeX > way'' would be to use \(...\). Except that \( and \) are fragile, and $...$ isn't. I think The LaTeX Companion or Lamport explicitly state that $...$ is more robust. > Under normal circumstances they are equivalent but some packages > may redefine \( and \) for their own purposes while $ (or something > with the same catcode) is a TeX primitive. > > I'm not sure there would any difference between $\displaystyle ...$ > (or the \(\displaystyle ... \)) and \[...\] besides some vertical > spacing and centering. What happens if there is an array? Arrays will set normally, it is with the multi-line constructs from the amsmath package that the trouble really starts. Frankly, getting a template that would allow us to obtain displayed maths _and_ get the baseline offset has been a nightmare (and is still unresolved). May I point you to http://www.xs4all.nl/~msneep/ articles/baseline.html for background information? Maarten |
|
From: Herbert S. <he...@wi...> - 2005-07-03 12:53:19
|
On Jul 3, 2005, at 7:24 AM, Pierre Chatelier wrote: >>>> - Since we're talking LaTeX, it would be better to write >>>> Display (\[...\]) >>>> because $$...$$ is, to be strict, incorrect. >>>> >>>> >>> I guess this is a debatable problem. I did never use \[...\] >>> myself, since I find $$ more handy. But I am certainly not a >>> LaTeX expert. What does the majority of people expect here (this >>> is a question for the mailing list) ? >>> >>> >> >> To quote Lamport on this (L. Lamport, "LaTeX, a document >> preparation system (LaTeX2e edition), page 233): "Plain TeX's $$ >> does not work properly; it has been replaced by the LaTeX commands >> \[ and \]." >> >> In short, $$ should not be used with LaTeX. >> > Ok, that makes sense. What about $ for inline mode ? Is there > another, better shortcut ? By the way, during the latexisation, I > do not even use \[ but $\displaystyle. Is it a potential problem ? > Howdy, Many people still use $...$ for in-line maths but a ``more LaTeX way'' would be to use \(...\). Under normal circumstances they are equivalent but some packages may redefine \( and \) for their own purposes while $ (or something with the same catcode) is a TeX primitive. I'm not sure there would any difference between $\displaystyle ...$ (or the \(\displaystyle ... \)) and \[...\] besides some vertical spacing and centering. What happens if there is an array? > >>>> But I think users tend to know enough of what's going on to be >>>> able to write | Display | Inline | Text | in those buttons and >>>> put \[...\] , etc., in a tooltip. >>>> >>> Here I disagree a little. For people not familiar with LaTeX's >>> vocabulary, the use of the button becomes obvious. Here again, >>> what do people think about that ? >>> >> People not familiar with LaTeX's vocabulary will have some trouble >> using LaTeXiT anyway. I think the descriptive names (which can be >> localized) on the buttons are better, with the command displayed >> in the tooltip as a backup. >> > Finally, it's fair to say that it would be, visually, less heavy. > > Regards, > > Pierre > I agree that the description should be enough. A tooltip would be a nice addition. I'd also propose just using ``LaTeX'' rather than ``LaTexise'' (British?) or ``LaTeXize'' (US?); solves the problem. Having the ``decimal point'' be the one used with the system localization would be nice too; luckily, most folks who use TeX seem to have been internationaliz(s)ed enough to understand either. Good Luck, Herb Schulz (he...@wi...) |
|
From: Pierre C. <pie...@cl...> - 2005-07-03 12:52:03
|
> A slider would be fine but there might be a display/entry box for > the ``extra boundary space'' in pt too so one could be more precise. In that case, I would prefer only an entry box. But so far, I really do not see how to add this control *nicely* in the interface. I made some tests, not very successful. If you have an idea... Pierre |
