Re: Position, Leaf/NonLeafPosition, wrapping positions
Guys, thanks for your inputs. That strengthens a bit the picture I have in mind. I'm wondering if the following makes any sense: We would have a list of page-level Knuth elements; some of those elements would be wrapper around line-level Knuth elements. Almost every element would contain a Position pointing to the LayoutManager that generated the element. Special elements created to achieve various effects (say, text-centering), would contain null Positions. The breaking algorithm would break the list of Knuth elements into chunks representing lines/pages. From that we would iterate over the non-null Positions, and for each one call position.getLM().addArea(position). That is, the position would notify its LM that its corresponding areas must be added. For page-level elements wrapping line-level elements, we would also iterate over the wrapped inline Positions. Now, does that picture represent the current code? If not, what is missing/wrong, apart from the many details relevant to each particular LM? Does that make sense? Thanks, Vincent Jeremias Maerki a écrit : On 07.03.2007 15:28:37 Andreas L Delmelle wrote: On Mar 7, 2007, at 09:07, Vincent Hennebert wrote: Hi Vincent, I have some questions regarding the handling of Position elements. I'm not familiar with that part of the code yet, and as there is little or no javadoc for those it's a bit difficult to guess their purposes just by looking at the code. I think you're not the only one with this problem... :/ Note that there is also an illustrious resetPosition() method, which currently seems to be used nowhere. All references to it seem to be circular. BlockLayoutManager.resetPosition() is only called by AbstractLayoutManager.reset(), which in turn is only called by one of the other LM's resetPosition(), etc. That's a left-over from the Keiron's and Karen's first approach before we introduced Knuth's algorithm. The resetting was used to go back to a certain position after deciding line/page breaks. When I merged in Luca's Knuth code I mostly removed most of this resetting because I thought we wouldn't need it anymore. Turns out I could have been wrong (changing available IPD topic). But maybe it's also good I didn't remove everything so we still know that there was such a mechanism. At some point we obviously have to resurrect it (if we need it again) or to remove it for good. The closest understanding that I have of those Positions is still a bit limited, I'm afraid, so I'm hoping others chime in to correct my mistakes or offer further clarification. (Just noticed that Luca already did; will share my thoughts in any case, to see if I may have misinterpreted something) snip/ That is all: as far as I get it... Oh, I think you pretty much got it. Jeremias Maerki
Re: Position, Leaf/NonLeafPosition, wrapping positions
Yes, that's pretty much my view of the whole thing. On 08.03.2007 18:29:07 Vincent Hennebert wrote: Guys, thanks for your inputs. That strengthens a bit the picture I have in mind. I'm wondering if the following makes any sense: We would have a list of page-level Knuth elements; some of those elements would be wrapper around line-level Knuth elements. Almost every element would contain a Position pointing to the LayoutManager that generated the element. Special elements created to achieve various effects (say, text-centering), would contain null Positions. The breaking algorithm would break the list of Knuth elements into chunks representing lines/pages. From that we would iterate over the non-null Positions, and for each one call position.getLM().addArea(position). That is, the position would notify its LM that its corresponding areas must be added. For page-level elements wrapping line-level elements, we would also iterate over the wrapped inline Positions. Now, does that picture represent the current code? If not, what is missing/wrong, apart from the many details relevant to each particular LM? Does that make sense? snip/ Jeremias Maerki
Re: Position, Leaf/NonLeafPosition, wrapping positions
On Mar 8, 2007, at 18:29, Vincent Hennebert wrote: thanks for your inputs. That strengthens a bit the picture I have in mind. I'm wondering if the following makes any sense: We would have a list of page-level Knuth elements; some of those elements would be wrapper around line-level Knuth elements. Almost every element would contain a Position pointing to the LayoutManager that generated the element. Special elements created to achieve various effects (say, text-centering), would contain null Positions. The breaking algorithm would break the list of Knuth elements into chunks representing lines/pages. From that we would iterate over the non-null Positions, and for each one call position.getLM().addArea(position). That is, the position would notify its LM that its corresponding areas must be added. For page-level elements wrapping line-level elements, we would also iterate over the wrapped inline Positions. Now, does that picture represent the current code? For the largest part, yes, I think so. The only difference is the addArea() part, which currently goes top- down. It is not the Position that notifies its LM that the areas must be added, but the LM that iterates over the Positions and adds their corresponding areas. Cheers, Andreas
Re: fop.bat needs patching
On Wed, Mar 07, 2007 at 04:32:09PM -0800, Nicol Bolas wrote: Well, consider this. I know what a .bat file is; I know how to use one. I don't know what a cmd or a js startup script is. If I need to modify the .bat file, I can read it, understand it, and use it without looking something up online. A lot of Windows users who would be interested in FOP are in pretty much the same boat. So what would be gained from using a relatively obscure script format rather than a .bat file? In the past three months we have had two incidents where the startup script fop.bat lagged behind the update of a jar file. One such incident forced me to cancel 100MB of candidate release files, fix that batch file and create and upload 100MB of new candidate release files. You would not gain anything as long as we suffer the pain of maintaining the startup script in the age-old, powerless batch language designed for x86 computers in 1990. We would gain the comfort of a more powerful language, which is able to find out itself if a jar file has changed version number. In addition, the javascript file offers customizability to the users. Until someone creates a comfortable GUI for FOP, you better learn what cmd and js files are. Or at least, you learn that you can execute them by double clicking on them, just as the batch file. B.T.W. the cmd and bat file languages are the same language on recent Windows systems. It is just that the batch file does not use more powerful features of that language, in order to enable you to run the same on a Windows 98 computer. My Windows 98 system broke down quite a while ago, but there seem to be people who are kinder to it, and have kept it alive until now. Simon, who prefers to spend his time and efforts on forward looking features -- Simon Pepping home page: http://www.leverkruid.eu
Re: [2007/02/11] fop.bat needs patching
I do not believe that most Windows machines came with a JavaScript interpreter. As such, expecting a user to have to install one in order to use FOP is an unnecessarily high bar. However, if the 'cmd' language and the 'bat' languages are fairly identical, feel free to change them. As long as the user doesn't have to install a program just to use FOP, I don't see a problem. Simon Pepping @ Home wrote: On Wed, Mar 07, 2007 at 04:32:09PM -0800, Nicol Bolas wrote: Well, consider this. I know what a .bat file is; I know how to use one. I don't know what a cmd or a js startup script is. If I need to modify the .bat file, I can read it, understand it, and use it without looking something up online. A lot of Windows users who would be interested in FOP are in pretty much the same boat. So what would be gained from using a relatively obscure script format rather than a .bat file? In the past three months we have had two incidents where the startup script fop.bat lagged behind the update of a jar file. One such incident forced me to cancel 100MB of candidate release files, fix that batch file and create and upload 100MB of new candidate release files. You would not gain anything as long as we suffer the pain of maintaining the startup script in the age-old, powerless batch language designed for x86 computers in 1990. We would gain the comfort of a more powerful language, which is able to find out itself if a jar file has changed version number. In addition, the javascript file offers customizability to the users. Until someone creates a comfortable GUI for FOP, you better learn what cmd and js files are. Or at least, you learn that you can execute them by double clicking on them, just as the batch file. B.T.W. the cmd and bat file languages are the same language on recent Windows systems. It is just that the batch file does not use more powerful features of that language, in order to enable you to run the same on a Windows 98 computer. My Windows 98 system broke down quite a while ago, but there seem to be people who are kinder to it, and have kept it alive until now. Simon, who prefers to spend his time and efforts on forward looking features -- Simon Pepping home page: http://www.leverkruid.eu -- View this message in context: http://www.nabble.com/fop.bat-needs-patching-tf3361048.html#a9387403 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: [2007/02/11] fop.bat needs patching
JScript is one of the Windows Scripting Host languages. It has been supported since Win9x, along with vbscript. Nicol Bolas [EMAIL PROTECTED] 09/03/2007 01:19 PM Please respond to fop-dev To: fop-dev@xmlgraphics.apache.org cc: Subject:Re: [2007/02/11] fop.bat needs patching I do not believe that most Windows machines came with a JavaScript interpreter. As such, expecting a user to have to install one in order to use FOP is an unnecessarily high bar. However, if the 'cmd' language and the 'bat' languages are fairly identical, feel free to change them. As long as the user doesn't have to install a program just to use FOP, I don't see a problem. Simon Pepping @ Home wrote: On Wed, Mar 07, 2007 at 04:32:09PM -0800, Nicol Bolas wrote: Well, consider this. I know what a .bat file is; I know how to use one. I don't know what a cmd or a js startup script is. If I need to modify the .bat file, I can read it, understand it, and use it without looking something up online. A lot of Windows users who would be interested in FOP are in pretty much the same boat. So what would be gained from using a relatively obscure script format rather than a .bat file? In the past three months we have had two incidents where the startup script fop.bat lagged behind the update of a jar file. One such incident forced me to cancel 100MB of candidate release files, fix that batch file and create and upload 100MB of new candidate release files. You would not gain anything as long as we suffer the pain of maintaining the startup script in the age-old, powerless batch language designed for x86 computers in 1990. We would gain the comfort of a more powerful language, which is able to find out itself if a jar file has changed version number. In addition, the javascript file offers customizability to the users. Until someone creates a comfortable GUI for FOP, you better learn what cmd and js files are. Or at least, you learn that you can execute them by double clicking on them, just as the batch file. B.T.W. the cmd and bat file languages are the same language on recent Windows systems. It is just that the batch file does not use more powerful features of that language, in order to enable you to run the same on a Windows 98 computer. My Windows 98 system broke down quite a while ago, but there seem to be people who are kinder to it, and have kept it alive until now. Simon, who prefers to spend his time and efforts on forward looking features -- Simon Pepping home page: http://www.leverkruid.eu -- View this message in context: http://www.nabble.com/fop.bat-needs-patching-tf3361048.html#a9387403 Sent from the FOP - Dev mailing list archive at Nabble.com.
