Cfrgtkky

Good day! Here I am trying to fix the space between running head last page of the breaking box. Here I am using enlarge top at break by=10pt because as per style continue should come at the top of the box. Here I used "overlay" for fixing continue style, Here my problem is, box last page more space taken between running head and the top of the box. I required same space as like the start of the box. Refer the screen shot attached and also suggest how to check the odd and even page condition inside the overlay.

MWE:

documentclass{book}



usepackage[skins]{tcolorbox}

tcbuselibrary{breakable}



begin{document}





newenvironment{curvebox}[1]{parparindent12ptaddvspace{12pt plus1pt minus1pt}%

letsourceboxsource%

begin{tcolorbox}[leftrule=0pt, boxrule=0pt, rightrule=0pt, toprule=0pt, bottomrule=1pt, breakable, before upper={parindent12pt},

%colframe=black,

colback=white, colframe=black,boxrule=.5pt, arc=4mm, bottomrule at break=.5pt,toprule at break=.5pt,

rounded corners,boxsep=1.5pt,bottom=4pt, bottomsep at break=6pt, topsep at break=5.5pt,

colbacktitle=white,

coltitle=black,

 enlarge top at break by=10pt,

overlay first={

         draw[line width=1mm]; 

        node[anchor=north east] at (frame.south east) {vbox to 0pt{vspace*{2pt}hbox to textwidth{hfill(textit{Continued})hspace*{-5pt}}}};},

    overlay middle={

        draw[line width=.5pt]; 

        draw[line width=.5pt]; 

        node[anchor=south west] at (frame.north west) {hspace*{-5pt}raisebox{2.5pt}{(textit{Continued})}};

        },

    overlay last={

        draw[line width=.5pt];

},

]parvskip6.6ptfontsize{8.5}{10.5}selectfontnoindent{{textbf{#1}parvskip7.6pt}}noindentignorespaces%

}{parvspace*{5pt}end{tcolorbox}%

paraddvspace{9pt plus1pt minus1pt}} 



    chapter{Economic feasibility}



    Economic feasibility cost is oftentimes the determining factor if the organization will move forward with the proposed solution. Differentiating the cost-effectiveness of the proposed solution as it relates with short- and long-term business goals can best facilitate the negotiation. Can the solution be implemented in phases allowing the organization to allocate funding incrementally?



    In the instance that there will be several vendors that will be considered as part of the request for proposal, Whitten and Bentley (2007) recommend evaluating the proposal based on the following criteria





    {Chapters 1} and {2} explained the projects development phase where the initiation and planning processes take place. Project management experts have varying opinion on when SDLC starts its life cycle. In searching through the literature, some authors associate the scope definition and problem identification as part of the initiating and planning phases (Whitten  Bentley, 2007). Other authors propose that SDLC coincides with the planning phase ({Williams, 2015}) while some suggests that SDLC is part of the PLC and the majority of the development starts at the execution phase. There is no absolute direction on when SDLC commences and it would vary based on the organizations own processes and methodology. Clinically, the nursing process of planning is conducted after a problem is identified and the care team agrees on a plan of care. Similarly, the SDLC is continuous wherein the systems planning of the product cycle.



    Economic feasibility--cost is oftentimes the determining factor if the organization will move forward with the proposed solution. Differentiating the cost-effectiveness of the proposed solution as it relates with short- and long-term business goals can best facilitate the negotiation. Can the solution be implemented in phases allowing the organization to allocate funding incrementally?



    In the instance that there will be several vendors that will be considered as part of the request for proposal, Whitten and Bentley (2007) recommend evaluating the proposal based on the following criteria



begin{curvebox}[Case Study 2.2: Patient Identification]

noindent

The standard symbols in process mapping consist of several shapes with specific use. An oval shape shows the input to start the process or the output at the end of the process. An arrow shows the direction of the process flow or step. A box or rectangle shows a task or activity being performed or executed. A diamond shape is a decision point whereby a question is asked that is answerable by either yes or no. There is only one arrow out of each activity box. If more than one arrow is needed, then it could be that a decision diamond needs to be asked. Other shapes represent a document or report, data or a subprocess (see {Figure 2.3}).



As introduced in the {Chapter 5}, flowcharts or maps play an important function in the assessment phase. As a tool, flowchart defines and provides visibility to the process by analyzing processes and/or clarifying a situation to improve knowledge and understanding of the organization. Through the use of steps and workflow sequences, relationships between steps are established in a picture representation or process map. The sequence of steps in a process, with different types of actions is displayed by boxes and other standard symbols facilitate the analysis of a solution to a given problem. This can be completed with Microsoft Visio or even in a word document if Visio is unavailable.



Scheduling current state and future state process sessions for the project team to participate through discussion and specifying each step in order will help clarify the gaps and design. The deliverable outcome of these process sessions are the flowcharts that provide knowledge on the process as a whole. This helps to bring common understanding and an awareness that users working in one part of the process must work collaboratively with those in other parts of the process so that the whole process can flow smoothly.



Reaching an understanding of the work process is part of the workflow analysis normally conducted before automating any process, information, and application of the organization. Focus groups or work groups may also be helpful for more in-depth exploration of topics that arise to better understand workflow and any potential barriers. These workgroup meetings can also discuss optimizing processes, review impacted policies, and procedures.



This analysis is focused on the physical design and integration of the software, which involves an illustration of how the application will function or work within the technical environment. The focus of the NIS in regards to technical requirements is to ask questions, raise considerations, and understand where the technical requirements impact the workflow. Identifying the system technical requirements may include hardware assessments, software features and functionality, database and reporting, as well as integration requirements. Hardware equipment needs may include desktop computers with keyboards, availability of electric outlets and cables for the additional computers, mobile workstations with computers, and connected printers for every inpatient unit, pharmacy, laboratory, radiology, and other clinical or patient care areas that would be affected. The repository and servers where the data will be held need to be taken into account before the implementation.



The infrastructure needs to be in place and invested in before the start of the project. The technical planning needs to include system maintenance once the application is operational, provision of ongoing help desk support, as well as, disaster recovery plan. Confidentiality and security of the system are important points that must be reviewed ensuring that the system is Health Insurance Portability and Accountability Act (HIPAA) compliant. It is essential to include subject matter experts such as the IT security, network, and desktop teams in the assessment phase. Technical questions have to be verified with the vendor particularly on what the system can do being that systems are deep with many layers. The technical components are the responsibility of the technical analyst that is part of the project team wherein he or she provides guidance in this process. Continuing with the same example for the blood transfusion verification project, {Table 6.6} lists examples of technical, security, and system support requirements.





This analysis is focused on the physical design and integration of the software, which involves an illustration of how the application will function or work within the technical environment. The focus of the NIS in regards to technical requirements is to ask questions, raise considerations, and understand where the technical requirements impact the workflow. Identifying the system technical requirements may include hardware assessments, software features and functionality, database and reporting, as well as integration requirements. Hardware equipment needs may include desktop computers with keyboards, availability of electric outlets and cables for the additional computers, mobile workstations with computers, and connected printers for every inpatient unit, pharmacy, laboratory, radiology, and other clinical or patient care areas that would be affected. The repository and servers where the data will be held need to be taken into account before the implementation.



The infrastructure needs to be in place and invested in before the start of the project. The technical planning needs to include system maintenance once the application is operational, provision of ongoing help desk support, as well as, disaster recovery plan. Confidentiality and security of the system are important points that must be reviewed ensuring that the system is Health Insurance Portability and Accountability Act (HIPAA) compliant. It is essential to include subject matter experts such as the IT security, network, and desktop teams in the assessment phase. Technical questions have to be verified with the vendor particularly on what the system can do being that systems are deep with many layers. The technical components are the responsibility of the technical analyst that is part of the project team wherein he or she provides guidance in this process.



This analysis is focused on the physical design and integration of the software, which involves an illustration of how the application will function or work within the technical environment. The focus of the NIS in regards to technical requirements is to ask questions, raise considerations, and understand where the technical requirements impact the workflow. Identifying the system technical requirements may include hardware assessments, software features and functionality, database and reporting, as well as integration requirements. Hardware equipment needs may include desktop computers with keyboards, availability of electric outlets and cables for the additional computers, mobile workstations with computers, and connected printers for every inpatient unit, pharmacy, laboratory, radiology, and other clinical or patient care areas that would be affected. The repository and servers where the data will be held need to be taken into account before the implementation.



The infrastructure needs to be in place and invested in before the start of the project. The technical planning needs to include system maintenance once the application is operational, provision of ongoing help desk support, as well as, disaster recovery plan. Confidentiality and security of the system are important points that must be reviewed ensuring that the system is Health Insurance Portability and Accountability Act (HIPAA) compliant. It is essential to include subject matter experts such as the IT security, network, and desktop teams in the assessment phase. Technical questions have to be verified with the vendor particularly on what the system can do being that systems are deep with many layers. The technical components are the responsibility of the technical analyst that is part of the project team wherein he or she provides guidance in this process. Continuing with the same example for the blood transfusion verification project, {Table 6.6} lists examples of technical, security, and system support requirements.





This analysis is focused on the physical design and integration of the software, which involves an illustration of how the application will function or work within the technical environment. The focus of the NIS in regards to technical requirements is to ask questions, raise considerations, and understand where the technical requirements impact the workflow. Identifying the system technical requirements may include hardware assessments, software features and functionality, database and reporting, as well as integration requirements. Hardware equipment needs may include desktop computers with keyboards, availability of electric outlets and cables for the additional computers, mobile workstations with computers, and connected printers for every inpatient unit, pharmacy, laboratory, radiology, and other clinical or patient care areas that would be affected. The repository and servers where the data will be held need to be taken into account before the implementation.



The infrastructure needs to be in place and invested in before the start of the project. The technical planning needs to include system maintenance once the application is operational, provision of ongoing help desk support, as well as, disaster recovery plan. Confidentiality and security of the system are important points that must be reviewed ensuring that the system is Health Insurance Portability and Accountability Act (HIPAA) compliant. It is essential to include subject matter experts such as the IT security, network, and desktop teams in the assessment phase. Technical questions have to be verified with the vendor particularly on what the system can do being that systems are deep with many layers. The technical components are the responsibility of the technical analyst that is part of the project team wherein he or she provides guidance in this process. %Continuing with the same example for the blood transfusion verification project, {Table 6.6} lists examples of technical, security, and system support requirements.





end{curvebox}







end{document}  

NEW ANSWER:

Ok, after playing around with things, I have found the exact solution that OP is requesting. I would have found it sooner, but I did not realize that the hooks library was not loaded, but required for several things. Once you load it, you can take advantage of hooks on the last page.

Using the last page hook, you can keep the original enlarge top at break by=10pt (for all the middle pages). Then, for the last page, you insert negative vertical space to pull it up.

Be aware, I cut out a lot of unnecessary formatting pieces. I also could not understand why the draw commands were used in the overlays, so I removed them. Finally, I removed all of the original text and used lipsum to create approximately the same length document. Using all these methods, the MWE is actually quite short now!

documentclass{book}



usepackage{lipsum}



usepackage[skins]{tcolorbox}

tcbuselibrary{breakable}

tcbuselibrary{hooks}%YOU MUST USE THIS FOR <extras last pre> KEY



begin{document}



newenvironment{curvebox}[1]{

tcbset{%

    colback=white,

    colframe=black,

    boxrule=0.5pt,

    breakable,

    arc=4mm,

    before upper={parindent=12pt},

    extras last pre={vspace*{-10pt}},

    enlarge top at break by=10pt,

    overlay first={%

        node[anchor=north east] at (frame.south east) {vbox to 0pt{vspace*{2pt}hbox to textwidth{hfill(textit{Continued})hspace*{-5pt}}}};

    },

    overlay middle={%

        node[anchor=south west] at (frame.north west) {hspace*{-5pt}{(textit{Continued})}};

    },

}%

begin{tcolorbox}

{{textbf{#1}parvskip7.6pt}}

}{%

end{tcolorbox}%

} 



    chapter{Economic feasibility}



    lipsum[1-3]



begin{curvebox}[Case Study 2.2: Patient Identification]

noindent

lipsum[1-11]



end{curvebox}



end{document}

Resulting document looks like this (across two, two-page images):

ORIGINAL ANSWER:

There is a line in your example that must be changed to remove the spacing at the top of the page.

enlarge top at break by=10pt,

should be changed to:

enlarge top at break by=0pt,

As for removing (Continued), I'm having some difficulty understanding exactly what you are asking/saying. It sounds like you want it only on the first page (not second or third pages) of the case study? If this is correct, remove this exact text (be careful not to remove characters before/after):

node[anchor=south west] at (frame.north west) {hspace*{-5pt}raisebox{2.5pt}{(textit{Continued})}};

EDIT:

Based on the comment, it seems there is a desire to keep the (Continued) text on all pages except for the last page of the case study. After playing around with some things, it seems either (1) impossible to accomplish both desired tasks or (2) using approaches that I am unaware of. For this reason, I present an alternative that accomplishes both things (i.e. keeping (continued) and fixing the vertical spacing).

Remove the space at the top, as I mentioned above (enlarge top at break by=0pt,).

The second task is to move the (Continued) text from the top of the middle pages to the bottom. Honestly, this looks much better to me. At the tops of the pages, you have page number, plus (Continued), plus Chapter 1: Economic Feasibility. If you modify the document, increase the length of the case study, or include additional case studies, you will quickly find that the headings on those pages will be "busy" with three header items.

It is also confusing to me to have (Continued) at the bottom of the first page...but at the top of the next page (and then completely missing on the last page). So, my proposal is to replace the existing node within overlay middle:

node[anchor=south west] at (frame.north west) {vbox to 0pt{vspace*{12pt}hspace*{-5pt}{(textit{Continued})}}};

with the node from overlap first:

node[anchor=north east] at (frame.south east) {vbox to 0pt{vspace*{2pt}hbox to textwidth{hfill(textit{Continued})hspace*{-5pt}}}};

Resulting in this:

NOTE:

As a general note, it seems you are mixing many different dimensions (e.g. pt, mm, etc.). It's rather confusing to look at. For example, you have:

draw[line width=1mm];

and a few lines below it:

draw[line width=.5pt]; 

I would suggest you keep these dimension types the same, especially if the value is effectively the same. It is much easier to identify identical things and different things later on, such as if you need to tweak the appearance.